我的微服務之路
故事開端
故事開始於一年半前，當時還在維護着公司的一套老項目，項目雖老，但是每天的pv，up都是過千萬的。理論上算得上是一個大項目，對於技術能力有一定的挑戰。
公司歷史悠久，項目架構龐雜，說實話進入公司之后好像沒有聽到如何強制的執行一些開發及代碼規范，比如插件啦，git指南啦，codestyle啦，codereview流程啦。大多數程序員每天的任務就是完成運營或者產品同學的需求，說實話經過多年的發展，有點挑戰的產品需求，或者革新比較大的改版需求早就讓前人做了，新來的產品或者運營同學基本沒有多少的需求或者革新可以做了，巧婦難為無米之炊。而開發人員做的基本就是sql改寫，html頁面的上線，代碼邏輯三層架構即可。
沒有架構師定時去分享一些架構經驗，也少有大型挑戰的項目給到開發同學去攻克與成長，說實話對於技術同學的成長是有一定限制的，所以如果有機會去做一個新項目，嘗試一些新技術，對於每個開發同學其實是一件開心的事情。
古老的技術棧
前面說了，公司經過十來年的發展，隨着業務的穩定，技術棧也相對穩定了，反過來說，技術棧穩定了，也就代表着輕易不敢在項目上動刀子。
公司歷史遺留的技術棧有過php，.net，到后來的開始轉型java，從單一的三層架構，后來分割的soa。一套業務系統里面，往往有着不一樣的架構思路與設計。
當我有機會去做一個新的項目的時候，還是使用spring mvc,mybatis坐着三層開發。有一天看到了微服務架構的文章，看的久了慢慢對微服務的各個模塊角色，開發方式，設計思想有了一定的理解，手癢想試試，想既然大項目沒機會動手動腳，我是不是可以自己嘗試用微服務的架構方式去重構古老的系統呢？
微服務架構的梳理
首先接觸到的概念是“服務化”，說道服務化，過去幾年市面上常見的解決方案多是圍繞着dubbo的rpc通信方案。
最近一年的微服務思想多是圍繞springcloud的方案。
dubbo用過很多次了，多是作為服務治理框架，在幾年前他的設計思想還是比較優秀的。但是經過這么多年的發展，這種服務治理框架的實現可以有多種方式了，我自己實現過基於spring框架的服務治理框架，服務發現用的是zookeeper，通信兩種netty和hessian，有機會說說這個。
當時spring cloud炒的很火，既然跟spring 有關，相信會勾起每個java開發人員的好奇心。
經過對於spring cloud工具集的學習，慢慢知道了一個標准的微服務架構所應該包含的功能點，如：
- 服務網關，主要為了統一驗證與授權，當然也可以做限流。
- 注冊中心，為了服務發現。
- 負載均衡。
- 異常處理與轉移，可做降級處理與異常處理。
- 等。
於是開始對老系統進行業務與服務抽離，在原有系統結構上我主要可以抽離出30多個服務，主要的有比如：
- 登錄服務 / 注冊服務；
- 授權解密；
- 評論 / 回復；
- Feed流；
- 粉絲；
- 積分 / 簽到；
- 頭像；
- 標簽；
抽離服務之后開始編碼，受夠了spring mvc繁雜的xml配置，決定使用spring boot。
第一次使用spring boot時候感覺像當年寫php 從thinkphp到codeigniter，像當年從.net webform到.net mvc2.0的感覺，爽。
於是：
- SpringBoot做代碼容器；
- 服務注冊與發現用的是eureka；
- 網關用的是zuul；
- 統一配置用的是spring cloud config；
自己嘗試跑起來之后基本順滑了。整體上對於微服務的架構有所實踐與了解了。
但是前文說了，項目老了基本沒啥重構空間了，會了微服務暫時用不上啊。
我的微服務架構
用過spring cloud一套解決方案基本可以作為內網項目之間的解決方案，但是如果直接面對外網，前文說的解決方案是否還有效呢？
相信很少有直接將zuul面向外網的吧，放心一點的網關還是nginx靠譜。
我現在的項目的主要方式是前后端分離方式，前端包括了html，移動端，pad等。后端主要提供restapi，這樣場景比較適合微服務的架構方式。
於是我們目前迭代到了下面的方式：
- 網關使用kong，主要借助nginx強大負載能力和kong本身豐富的插件，和當年使用kibana一樣爽。
- spring boot一如既往的寫起代碼爽。
- 注冊發現用zookeeper，這個基本屬於行業標配。
- 統一配置用disconf，不爽的一點每次修改配置都需要重新發包，准備考慮用springcloud config，或者自己開發。
- 日志監控，一如既往的elk。
現在版本迭代的任務，基本交給質量管理團隊，基於mesos marathon 的docker基本交給了運維團隊，k8s暫時還搞不明白。
對了，換了團隊之后，身邊有了大牛可以學習的對象，對於項目開發的理解，對於技術團隊的搭建，對於工程師團隊的培養，對於數據化運營產品及團隊合作與加班這件事情都有了一些新的看法，以后交流。
