公司說我們的開發方式是敏捷開發,實際上只是使用了一些敏捷開發的方法,只有遵守敏捷開發的價值觀和原則，才能算是敏捷開發。微服務也是一樣，不是說拆分成多個服務去部署，就叫做微服務。也不是採用市面上常用的微服務框架，就是微服務了。 上面這段話是我對微服務的簡單理解。 隨著公司業務的發展，部門領導要求其中一 ...
公司說我們的開發方式是敏捷開發,實際上只是使用了一些敏捷開發的方法,只有遵守敏捷開發的價值觀和原則，才能算是敏捷開發。微服務也是一樣，不是說拆分成多個服務去部署，就叫做微服務。也不是採用市面上常用的微服務框架，就是微服務了。
上面這段話是我對微服務的簡單理解。
隨著公司業務的發展，部門領導要求其中一個業務量比較大的要做負載。只給了一周的時間，包括開發和自測。因為時間比較緊，採用了最簡單快捷的處理方式：緩存統一放Redis,起了一個輔助項目來做公共和定時器等方面的處理。
此種方式基本把壓力推到了Redis中，包括緩存的讀取、序列化等工作，基本上運行正常。突然有一次發版，因一些原因，停掉了其中一臺服務（詳見https://www.cnblogs.com/fishsky/p/10593233.html），導致在業務高峰期出現了請求超時（數據載入不出來的情況）。
重啟開啟另外一臺負載後 ，運行正常。過了兩天，又出現部分請求超時的情況。定位看到，其中一臺負載遇到了瓶頸，追查原因是haproxy採用的source的負載規則（以請求源IP為判斷，轉發到一臺伺服器後，後面只會到那台機子上）。為了避免再次出現情況，部署多了一臺機子，即共3台，進行負載，採用的是balance roundrobin （輪詢），基本穩定下來。
此時，運維方面提出了採用Dubbo+zookeeper+RabbitMQ+SpringMVC/Springboot（分散式服務架構）來提升系統的可靠性和穩定性。
對於此方案，初衷是好的。不過要實現落地，達到公司系統架構的調整，直接引入這套架構，並不是最好的選擇。投入的成本較高。如果不採用微服務（或者分散式服務架構）能否解決現在的問題，答案是肯定的。
好像有點偏離主題了，按現在我們就假設現在是引入微服務來解決出現的問題。
首先要解決的問題就是把目前的系統做分解（拆分），做到服務之間不相互調用、不用花大力氣解決各個服務之間的數據一致性問題。
這個也是微服務的真正難點（並非在於技術實現，而是業務的劃分），做到微服務的第一步是識別限界上下文。
對業務的劃分，目前有一套從系統分析到軟體建模的方法論：領域驅動設計。它要解決的問題是：將業務概念和業務規則轉換成軟體系統中概念和規則，從而降低或隱藏業務複雜性，使系統具有更好的擴展性，以應對複雜多變的顯示業務問題。
想做微服務架構，首先是不要使用微服務。如果將一個整體服務貿然做成微服務，引入的複雜度會吞噬掉你以為的優勢。
可以採用，讓不同的限界上下文先各自獨立演化，等到它演化到值得獨立部署了，再來考慮微服務拆分的事情。那時各種微服務（分散式服務）的技術，才是真正上場的時候。
作者：魚天翱
出處：https://www.cnblogs.com/fishsky
版權歸作者所有，轉載請註明出處
