【摘要】我一直堅持認為微服務很好，但是如果我們為了使用微服務而使用的話將會傷其自身，從單塊系統到微服務的是需要逐步演進的過程，如果前期沒有調研，沒有一個整體規劃，後期在做的時候會發現，需要做的事情只會越來越多，尤其是對於快速發展的創業型公司來說。
微服務是銀彈嗎？自2014年“微服務”一詞真是越來越火，不談Microservices彷佛就out了，那麼我們先來看微服務具有哪些特點：
組件以服務的形式提供
圍繞業務功能進行組織
強化終端與弱化管道
產品而不是項目
獨立佈署
單一職責
去中心化
DevOps與組織架構
我要講的故事開始了
A公司的技術架構體系目前還是以集群擴展體系為主，我們可以看下圖所示，在這種體系結構中，可以看到應用都是單塊結構，但是單塊結構的應用具有擴展性，通過佈署在多個Tomcat上實現應用的集群，所有的應用都去訪問同一個數據庫（這個庫可以假設為Oracle數據庫），數據庫間採用DataGuard來實現主從同步，讀庫只具有讀取功能，為後臺數據統計功能提供數據查詢和統計服務。目前業務請求的併發量每分鐘有幾十筆交易，看起來這套架構還是能夠支撐目前的業務發展的。
突然有一天客戶在做活動的時候，監控中心各種告警，在每分鐘500tps的時候很多請求超時，監控顯示目前的服務器不能支撐這麼大的併發量，於是快速增加服務器佈署應用上線，發現根本沒用，加了和沒加一樣，加幾臺都一樣，運維和DBA發現此時的數據庫壓力非常大，好不容易熬過這段是時間後，團隊成員痛定思痛一致認為，目前的架構體系已經不能支持業務的發展，微服務開始快速推進。
其中微服務的數據去中心化核心要點是：
每個微服務有自己私有的數據庫持久化業務數據。
每個微服務只能訪問自己的數據庫，而不能訪問其它服務的數據庫。
某些業務場景下，需要在一個事務中更新多個數據庫。這種情況也不能直接訪問其它微服務的數據庫，而是通過對於微服務進行操作。
數據的去中心化，進一步降低了微服務之間的耦合度。
最終經過服務化改進後，變成了如下圖所示的樣子：
上圖看起來是不是很棒，服務拆分是不是很清晰？
於是問題隨後就來了：
以前團隊一共就10個人只負責一二個項目，現在突然增加到平均每人維護二三個項目，上線還是採用由運維手工打war包上線，如果有修改的配置文件，則運維同學一臺一臺的進行修改，不僅容易上線出錯，而且每次上線都會搞到半夜。
根據上面提到的數據去中心化原則，數據庫拆分出來了，一個服務一個數據庫實例，但是對後臺統計系統來說就是惡夢，數據庫拆分出來了統計工作、報表工作該怎麼辦呢？這部分工作還做不做呢？有人說可以分開統計啊，一個庫一個庫的來，可是這樣的工作量將是巨大的。
機房的雙活問題，對於金融公司來說雙活還是很關鍵的一項技術指標，對於應用雙活來說，其實還是比較容易實現，但是對於數據庫來說確是一個技術問題了，對於Oracle數據庫來說，用Oracle官方提供的OGG（Oracle GoldenGate）來進行數據同步的話，根據論壇上面查看的資料可以看出，OGG坑非常多，而且也容易丟數據，更重要的是貴。採用Oracle的LogMiner來進行同步，同步的數據將不是實時的，會有一定延時而且在定時讀取方面的工作上還需要自己進行開發，採用Oracle的DataGuard也只能做主從同步，卻不能做主主雙活。於是通過調研過後，最終還是決定自己獨立開發。
使用Dubbo或者Spring Cloud就是微服務了嗎？好吧，使用了Dubbo以後發現還有非常多的工作需要做，Dubbo只是一個服務治理框架而已，還需要開發分佈式調用監控系統、統一配置管理中心，統一定時調度，還要在每個服務中做防重冪等，還要做併發限流，緩存也要根據不同的服務做隔離等等工作。
那我們用Spring Cloud做一個大一統的整合可以嗎？於是看到Spring Cloud原來有這些坑啊：
註冊IP問題
早期的Spring Cloud Eureka在註冊獲取網卡IP時，不能區分外網網卡和內網網卡，如果安裝了虛擬機和Docker也不能區分虛擬網卡，每次啟動註冊的IP都有可能不一樣，如果要註冊為外網網卡IP，那運行帶寬就不夠，這個bug應該說是比較嚴重的問題，因此重寫了網卡IP獲取的邏輯來解決，同時也反饋給了Spring Cloud團隊，再後期的版本中添加了網卡接口排序和通過名稱過濾的功能來得到解決。
HealthCheck的問題
在一些極小概率的情況下，會導致Eureka Server下線微服務實例，出現“Remote status from Eureka server is down”的問題，即便是重啟微服務也無濟於事，不過已經有碼友在Spring Cloud 官方GitHub貼出瞭解決方法的issue。
Feign使用不當帶來的性能問題
其他的小坑也就忍了，大坑卻不能。於是去各大社區討論發現原來大家都對Cloud的不少組件進行了二次封裝。
回顧一下
上面用了很大的篇幅各種吐槽，那麼我們說微服務好嗎？我一直堅持認為微服務很好，但是如果我們為了使用微服務而使用的話將會傷其自身，從單塊系統到微服務的是需要逐步演進的過程，如果前期沒有調研，沒有一個整體規劃，後期在做的時候會發現，需要做的事情只會越來越多，尤其是對於快速發展的創業型公司來說。
就拿我上面舉的例子來看，數據庫自身壓力大，經過分析看出其實是很多SQL沒有加索引，大量使用數據庫悲觀鎖，大表的數據一直長期積累沒有遷移出去所致。當單塊系統遇到了性能問題後，如果認真分析了性能的根源，也許還會為我們做服務化演進爭取了更多的時間。
最後想說一句，對於中小公司來說，如果業務發展非常快速，人員不足的情況下，我們更需要的是在業務發展和架構優化間做平衡，逐步演進，而不是快速使用。