個人微服務之路

個人微服務之路

---

故事開端

故事開始於一年半前，當時還在維護着公司的一套老項目，項目雖老，可是天天的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暫時還搞不明白。

對了，換了團隊以後，身邊有了大牛能夠學習的對象，對於項目開發的理解，對於技術團隊的搭建，對於工程師團隊的培養，對於數據化運營產品及團隊合做與加班這件事情都有了一些新的見解，之後交流。