? ? ? ?作為公司的CTO，我入職公司已經有2年半了，從公司A輪開始，一直到現在的B+輪；從一個工程，到現在40多個微服務；從最早的只有一個mysql實例，到現在我們有十幾個數據庫實例，還有hbase、hybrid for mysql、hadoop、maxcompute、poloDB等存儲演變；從當時只有兩臺nginx單點，到現在的lsb（阿里云LVS）、網關（spring cloud zuul → spring cloud? gateway）、微服務負載均衡（ribbon）等；我們走過很多路、踩過很多抗，至今為止回憶起來，都覺得是一筆寶貴的財富。從這篇文章開始，我想一邊回憶，一邊隨筆，把我們走過的這些路都記錄下來，希望這些經歷能給予看到這篇文章的人一些幫助。
? ? ? ?記得剛到公司的時候，公司的技術部門大概有12人左右，在一個大廠房里，當時是2個安卓、2個IOS、4個后端、2個測試、2個前端。我記得我第一次給大家開會說道，我們今年要全力的提升技術架構，為公司下一個階段做好儲備.......當時的話，我記得我給予了大伙很大的壓力，我以為這樣的壓力會讓大家更加有危機感，好可以更加拼命的去工作，但我完全想錯了；在未來的2周內，離職了近半數人...
? ? ? ?我通過和每一個離職員工交流，我發現了問題，這些員工并不是那些985、211出來的，上一家公司的背景也是很一般，他們享受慣了安逸，并沒有很明確的目標。所以，他們認為后面一定會很辛苦，而為這樣的公司，沒有必要付出這么多。
? ? ? ?當時我記得還剩下來7名員工吧，而后來，這七名員工中，有四人一直跟我們戰斗下來，現在成為了我們的核心人員，我應該為他們鼓鼓掌，我發現這幾名員工他們同樣是沒有明確的目標，不是985、211，但他們有一項非常牛逼的能力——抗壓力能力。其實當時的后端的工程是整個放在一個工程里的，雖然也有做服務化，但這個服務化是上一任CTO為了應對未來工程獨立化提前做的，我倒覺得這是一個相當不錯的選擇，既沒有讓工程變得復雜，又能為未來考慮；當然，如果都放在一個工程里，去服務化，也不失為一個good idea。我記得我來做的第一件事兒就是服務化的拆分，把dubbo工程獨立出來，拆出來一個個的project。
當時的架構圖就是這個樣子，所有的工程都在一個打的工程里，里面有dubbo的，有springboot1.x的，大概我記得一共有13個工程吧。這帶來了一個頭疼的問題，版本號和打包時間長的問題，所有的pom都依賴于最外層的一個大的pom，所以，每次打包都要全量的打，時間非常久。其次，某一個工程報錯，會導致整個打包失敗，效率比較低。因此，第一件事就是，把dubbo、web工程（spring boot）都獨立出來。
獨立化推進的過程還是很艱辛，版本號的沖突，代碼的強耦合都給我們帶來的了很大的負擔，我們采用一個個工程慢慢獨立的策略，新工程當然全部都采用獨立化的dubbo；做了這些之后，每個后端就可以有了owner業務的概念了，大家不再是為了實現一個工程到處去其他工程中零散的寫很多代碼；而出現了“支持”的概念，一次版本迭代不再是一個人可以完成的了，需要幾個人同事迭代來進行開發；彼此的代碼解耦，單元測試解耦，發布解耦等帶來了很多好處，到此為止，架構1.1時代我們花費了小半年的時間終于贏來了全面的解耦。
? ? ? ?其實很多公司目前還是這一套架構體系，無非是在這套體系會搭配很多中間件來解決未來會發生的問題，這個我會在架構演變的過程中，慢慢把每個中間件引進的時機和作用以及解決的問題來講解的，我相信這樣帶有事件時間線的講解，會讓大伙更生動的理解，我們公司技術演變過程中的“進化”。
