知識星球
現在，在網際網路圈子裡，不知道何時微服務這個概念已經深入到了我們圈內的各個角落，似乎如果不趕上這個潮流，公司的產品就將被淘汰了。
這個專場開場時，老師給我們說了個他的一段經歷。
一天他鄰居問他：“你的微服務課程我可以去聽麼？”
老師很是驚訝，說：“你做微商的怎麼這麼好學呀，你知道啥是微服務麼？”
鄰居說：“微服務不是為微商服務的麼？”
當然這略帶有點喜劇性了，不過對於微服務，真的是和我們理解的那樣麼？我在聽這場分享之前我一直認為，微服務不就是把業務按照功能模組切割，讓他獨立出來麼？
聽完這場分享，對微服務的定義，有了全新的認識。
1、微服務不是簡單的模組切割
目前業內對微服務存在的誤解有很多，這裡ThoughtWorks的架構師和堅老師給我們列出來幾點：
-
構建HTTP服務，實用Docker容器執行它，並且用Kubernets做叢集管理，就是微服務
-
使用API Gateway和服務發現以及服務registry，這就是微服務
-
使用Spring Boot框架構建http服務，並使用Netflix OSS，這就是微服務
-
使用Azure Service Fabric 構建並且執行應用程式，這就是微服務
-
構建輕量級的RESTful API，這就是微服務
-
有很多框架聲稱是微服務框架。使用這些框架的任意一種來構建應用程式，這就是微服務
看完這些，我就有點蒙圈了，那到底怎樣的才算微服務呢？下麵是老師對微服務的一個概括：
微服務架構是一種架構樣式，它提倡將單一應用程式劃分成一組小的服務，每個服務執行在其獨立的行程中，服務間採用輕量級的通訊機制互相溝通(通常是基於HTTP協議的RESTful API)。每個服務都圍繞著具體業務進行構建，並且能夠被獨立的部署到生產環境、類生產環境等。
同時和堅老師給我們分享了微服務具有以下幾點特點：
-
透過服務進行元件化
-
圍繞業務能力組織
-
做產品而不是做專案
-
只能端點與傻瓜管道
-
去中心化地治理技術
-
去中心化地管理資料
-
基礎設施自動化
-
容錯設計
-
演進式設計
我這裡的理解是微服務其實是圍繞業務能力組織進行劃分的一整套服務叢集，但是該怎麼劃分呢？他的粒度是什麼呢？
2、別一不小心把微服務切成了小的單體
假設有一天你的系統已經進行了“微服務”改造，由於你的業務發展，新的需求如潮水般湧來，漸漸的發現某些“微服務”開始慢慢的膨脹起來。
發現膨脹的“微服務”有一部分業務又需要拆分了，而且這個服務內部還高度耦合，這不就又變成了，拆分之前的服務了麼？
你拆分成的不是微服務，而是一個小的單體。
關於怎麼拆分微服務，和堅老師給我推薦了一個叫DDD服務設計的思想：
要求我們從業務視角去分離複雜度，最終標的都是為最求高響應力。
讓業務架構和系統架構形成系結關係，從而當我們去響應業務變化調整業務架構時，系統架構的改變是隨之而發的。
雖然短短的兩句話，但是要理解做好，真不是那麼容易，還待深入學習。
目前微服務只存在一個概念性的階段，要想將我們現有的服務切分成微服務，按照什麼標準進行切分，不同的行業，不同的業務場景，將是不同的，這是一個難題？
當我們辛辛苦苦的把業務切成了一個一個小的服務在跑時，如果哪天業務發展，發現這兩個服務還是和在一起跑比較好，這時，你將面臨的不是單單的把兩個程式碼合在一起這麼簡單。
程式碼上的衝突，修改上下游的依賴，部署架構都將是一個挑戰。微服務的合併，比拆分更難。
3、一個完整的微服務離不開完善的自動化運維
當我們的專案被拆分成了微服務線上上跑了，我們的開發看到的將不再是一整個業務的程式碼，而是一個一個小的模組服務。
我們的開發將面臨：我們得把整體的所有服務瞭解個遍，或者相關的服務模組瞭解完。
如果不能瞭解完，將會出現：在版本迭代時，我們修改的程式碼，能保證這個服務上沒問題，不能保證上線後對其他的業務不會有影響。
對於這個問題，微軟的MVP陳鋒逸老師提出了一個建議，藉助一些程式碼即架構的工具來彌補這塊。
微服務落地，我們還將面臨，我們的服務散落在各個地方，運維的同事將怎麼進行監控，怎麼知道此時此刻哪個服務掛了，哪個服務超載了，超載時我們怎麼進行擴容，這都是我們要解決的問題。
還有，如果我們辛辛苦苦做成了微服務，在版本釋出時，怎麼保證線上所有容器的版本一直性，也是要解決的問題。
這一系列的問題就涉及到可持續性交付這塊了，從開發提交程式碼，到測試，到構建，再到測試用例的改寫，最後到生產這一連貫的工作，怎麼讓他們自動化？如果做不到自動化，那投入的成本將可能是傳統的架構的N倍。
4、結束語
我不是一個架構師，只是一個小小的開發者，所有行文都是按照一個開發者的角度結合今天老師講的所寫，所以可能有諸多不恰當的措詞，歡迎指正。
原文連結：
https://www.ironz.com/view/ironcloudweifuwu/25.html
