文章每週持續更新，「三連」讓更多人看到是對我最大的肯定。可以微信搜尋公眾號「 後端技術學堂 」第一時間閱讀（一般比部落格早更新一到兩篇）
單體式應用程式
與微服務相對的另一個概念是傳統的「單體式應用程式」( Monolithic application )，單體式應用內部包含了所有需要的服務。而且各個服務功能模組有很強的耦合性，也就是相互依賴彼此，很難拆分和擴容。
說在做的各位都寫過單體程式，大家都沒意見吧？給大家舉個例子，剛開始寫程式碼你寫的helloworld程式就是單體程式，一個程式包含所有功能，雖然helloworld功能很簡單。
單體應用程式的優點
開發簡潔，功能都在單個程式內部，便於軟體設計和開發規劃。 容易部署，程式單一不存在分散式叢集的複雜部署環境，降低了部署難度。 容易測試，沒有各種複雜的服務呼叫關係，都是內部呼叫方便測試。
單體應用程式的缺點
單體程式的缺點一開始不是特別明顯，專案剛開始需求少，業務邏輯簡單，寫程式碼一時爽，一直爽。噩夢從業務迭代更新，系統日益龐大開始，前期的爽沒有了，取而代之的是軟體維護和迭代更新的無盡痛苦。
由於單體式應用程式就像一個大型容器一樣，裡面放置了許多服務，且他們都是密不可分的，這導致應用程式在擴充套件時必須以「應用程式」為單位。
當裡面有個業務模組負載過高時，並不能夠單獨擴充套件該服務，必須擴充套件整個應用程式（就是這麼霸道），這可能導致額外的資源浪費。
此外，單體式應用程式由於服務之間的緊密度、相依性過高，這將導致測試、升級有所困難，且開發曲線有可能會在後期大幅度地上升，令開發不易。相較之下「微服務架構」能夠解決這個問題。
微服務
微服務 (Microservices) 就是一些協同工作小而自治的服務。
❝2014年，Martin Fowler 與 James Lewis 共同提出了微服務的概念，定義了微服務是由以單一應用程式構成的小服務，自己擁有自己的行程與輕量化處理，服務依業務功能設計，以全自動的方式部署，與其他服務使用 HTTP API 通訊。同時服務會使用最小的規模的集中管理 (例如 Docker) 能力，服務可以用不同的程式語言與資料庫等元件實現 。「維基百科」
❞
舉例
還是拿前面的 helloworld 程式來舉栗子，想象一下你是 helloworld 公司的 CTO（老闆還缺人嗎？會寫程式碼的那種），假設你們公司的 helloworld 業務遍佈全球，需要編寫不同語種的 helloworld 版本，分別輸出英語、日語、法語、俄語...現在世界有6000多種語言（奇怪的知識又增加了）。
有人會說這還不簡單我用switch case語句就完事了，同學，不要較真我就是舉個例子，現實中的業務比 helloworld 複雜多了。好了，我們姑且認為按語言輸出是個龐大複雜的工作，這時候就可以用微服務架構了，架構圖如下：
微服務與SOA
「面向服務的體系結構」 SOA (Service-Oriented Architecture) 聽起來和微服務很像，但 SOA 早期均使用了匯流排模式，這種匯流排模式是與某種技術棧強繫結的，比如：J2EE。這導致很多企業的遺留系統很難對接，切換時間太長，成本太高，新系統穩定性的收斂也需要一些時間，最終 SOA 看起來很美，但卻成為了企業級奢侈品，中小公司都望而生畏。
此外，實施SOA時會遇到很多問題，比如通訊協議（例如SOAP)的選擇、第三方中介軟體如何選擇、服務粒度如何確定等，目前也存在一些關於如何劃分系統的指導性原則，但其中有很多都是錯誤的。SOA並沒有告訴你如何劃分單體應用成微服務，所以在實施SOA時會遇到很多問題。
這些問題再微服務框架中得到很好的解決，你可以認為微服務架構是SOA的一種特定方法。
微服務架構
合久必分，鑑於「單體應用程式」有上述的缺點，單個應用程式被劃分成各種小的、互相連線的微服務，一個微服務完成一個比較單一的功能，相互之間保持獨立和解耦合，這就是微服務架構。
微服務優點
相對於單體服務，微服務有很多優點，這裡列舉幾個主要的好處
技術異構性
不同服務內部的開發技術可以不一致，你可以用java來開發helloworld服務A，用golang來開發helloworld服務B，大家再也不用為哪種語言是世界上最好的語言而爭論不休。
為不同的服務選擇最適合該服務的技術，系統中不同部分也可以使用不同的儲存技術，比如A服務可以選擇redis儲存，B服務你可以選擇用MySQL儲存，這都是允許的，你的服務你做主。
隔離性
一個服務不可用不會導致另一個服務也癱瘓，因為各個服務是相互獨立和自治的系統。這在單體應用程式中是做不到的，單體應用程式中某個模組癱瘓，必將導致整個系統不可用，當然，單體程式也可以在不同機器上部署同樣的程式來實現備份，不過，同樣存在上面說的資源浪費問題。
可擴充套件性
龐大的單體服務如果出現效能瓶頸只能對軟體整體進行擴充套件，可能真正影響效能的只是其中一個很小的模組，我們也不得不付出升級整個應用的代價。這在微服務架構中得到了改善，你可以只對那些影響效能的服務做擴充套件升級，這樣對症下藥的效果是很好的。
簡化部署
如果你的服務是一個超大的單體服務，有幾百萬行程式碼，即使修改了幾行程式碼也要重新編譯整個應用，這顯然是非常繁瑣的，而且軟體變更帶來的不確定性非常高，軟體部署的影響也非常大。在微服務架構中，各個服務的部署是獨立的，如果真出了問題也只是影響單個服務，可以快速回滾版本解決。
易優化
微服務架構中單個服務的程式碼量不會很大，這樣當你需要重構或者優化這部分服務的時候，就會容易很多，畢竟，程式碼量越少意味著程式碼改動帶來的影響越可控。
微服務缺點
我們上面一直在強調微服務的好處，但是，微服務架構不是萬能的，並不能解決所有問題，其實這也是微服務把單體應用拆分成很多小的分散式服務導致的，所謂人多手雜，服務多起來管理的不好各種問題就來了。
為了解決微服務的缺點，前輩們提出了下面這些概念。
服務註冊與發現
微服務之間相互呼叫完成整體業務功能，如何在眾多微服務中找到正確的目標服務地址，這就是所謂「服務發現」功能。
常用的做法是服務提供方啟動的時候把自己的地址上報給「服務註冊中心」，這就是「服務註冊」。服務呼叫方「訂閱」服務變更「通知」，動態的接收服務註冊中心推送的服務地址列表，以後想找哪個服務直接發給他就可以。
服務監控
單體程式的監控運維還好說，大型微服務架構的服務運維是一大挑戰。服務運維人員需要實時的掌握服務執行中的各種狀態，最好有個控制皮膚能看到服務的記憶體使用率、呼叫次數、健康狀況等資訊。
這就需要我們有一套完備的服務監控體系，包括拓撲關係、監控（Metrics）、日誌監控（Logging）、呼叫追蹤（Trace）、告警通知、健康檢查等，防患於未然。
服務容錯
任何服務都不能保證100%不出問題，生產環境複雜多變，服務執行過程中不可避免的發生各種故障（當機、過載等等），工程師能夠做的是在故障發生時儘可能降低影響範圍、儘快恢復正常服務。
程式設計師為此避免被祭天，需要引入「熔斷、隔離、限流和降級、超時機制」等「服務容錯」機制來保證服務持續可用性。
服務安全
有些服務的敏感資料存在安全問題，「服務安全」就是對敏感服務採用安全鑑權機制，對服務的訪問需要進行相應的身份驗證和授權，防止資料洩露的風險，安全是一個長久的話題，在微服務中也有很多工作要做。
服務治理
說到「治理」一般都是有問題才需要治理，我們平常說環境治理、汙染治理一個意思，微服務架構中的微服務越來越多，上面說的那些問題就更加顯現，為了解決上面微服務架構缺陷「服務治理」就出現了。
微服務的那些問題都要公司技術團隊自己解決的話，如果不是大型公司有成熟的技術團隊，估計會很頭大。幸好，有巨人的肩膀可以借給我們站上去，通過引入「微服務框架」來幫助我們完成服務治理。
微服務框架
介紹一些業界比較成熟的微服務框架。
Dubbo
是阿里巴巴公司開源的一個Java高效能優秀的服務框架，使得應用可通過高效能的 RPC 實現服務的輸出和輸入功能，可以和 Spring框架無縫整合。 Apache Dubbo |ˈdʌbəʊ| 是一款高效能、輕量級的開源Java RPC框架，它提供了三大核心能力：面向介面的遠端方法呼叫，智慧容錯和負載均衡，以及服務自動註冊和發現 。2011 年末對外開源，僅支援 Java 語言。
官網：http://dubbo.apache.org/zh-cn/
Tars
騰訊內部使用的微服務架構 TAF（Total Application Framework）多年的實踐成果總結而成的開源專案。 僅支援 C++ 語言，目前在騰訊內部應用也非常廣泛。2017 年對外開源，僅支援 C++ 語言。
原始碼： https://github.com/TarsCloud/Tars/
「本命鵝廠 TARS 框架介紹 PPT 已下載，不想自己麻煩去找的同學，在我公眾號「後端技術學堂」回覆「tars」獲取。」
Motan
是新浪微博開源的一個Java 框架。Motan 在微博平臺中已經廣泛應用，每天為數百個服務完成近千億次的呼叫。於 2016 年對外開源，僅支援 Java 語言。
官方指南： https://github.com/weibocom/motan/wiki/zh_userguide
gRPC
是Google開發的高效能、通用的開源RPC框架，其由Google主要面向移動應用開發並基於HTTP/2協議標準而設計，基於ProtoBuf(Protocol Buffers)序列化協議開發。本身它不是分散式的，所以要實現上面的框架的功能需要進一步的開發。2015 年對外開源的跨語言 RPC 框架，支援多種語言。
中文教程：https://doc.oschina.net/grpc?t=58008
thrift
最初是由 Facebook 開發的內部系統跨語言的高效能 RPC 框架，2007 年貢獻給了 Apache 基金，成為 Apache 開源專案之一， 跟 gRPC 一樣，Thrift 也有一套自己的介面定義語言 IDL，可以通過程式碼生成器，生成各種程式語言的 Client 端和 Server 端的 SDK 程式碼，支援多種語言。
微服務框架和RPC
很多人對這兩個概念有點混淆，微服務框架上面我們說過了，我們再來看下RPC的概念。
什麼是RPC
RPC (Remote Procedure Call)遠端過程呼叫是一個計算機通訊協議。我們一般的程式呼叫是本地程式內部的呼叫，RPC允許你像呼叫本地函式一樣去呼叫另一個程式的函式，這中間會涉及網路通訊和程式間通訊，但你無需知道實現細節，RPC框架為你遮蔽了底層實現。RPC是一種伺服器-客戶端（Client/Server）模式，經典實現是一個通過「傳送請求-接受回應」進行資訊互動的系統。
兩者關係
RPC和微服務框架的關係我的理解，微服務框架一般都包含了RPC的實現和一系列「服務治理」能力，是一套軟體開發框架。我們可以基於這個框架之上實現自己的微服務，方便的利用微服務框架提供的「服務治理」能力和RPC能力，所以微服務框架也被有些人稱作RPC框架。
下一代微服務架構
Service Mesh（服務網格）被認為是下一代微服務架構，Service Mesh並沒有給我們帶來新的功能，它是用於解決其他工具已經解決過的服務網路呼叫、限流、熔斷和監控等問題，只不過這次是在Cloud Native 的 kubernetes 環境下的實現。
特點
Service Mesh 有如下幾個特點：
應用程式間通訊的中間層 輕量級網路代理 應用程式無感知 解耦應用程式的重試/超時、監控、追蹤和服務發現
目前兩款流行的 Service Mesh 開源軟體 [Istio](https://istio.io/) 和 [Linkerd](https://linkerd.io/)都可以直接在kubernetes 中整合，其中Linkerd已經成為雲原生計算基金會 CNCF (Cloud Native Computing Foundation) 成員。
Why Service Mesh
為什麼現有微服務架構已經解決的問題還要用Service Mesh呢？這個問題問的好。
回答問題之前，先看下istio.io上對service mesh的解釋，我覺得挺好的，摘抄出來：
❝As a service mesh grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often has more complex operational requirements, like A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication.
makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, **with few or no code changes in service code. **
❞
試著總結一下：隨著微服務的增多複雜程度也增加，管理變得更加困難，微服務架構雖然解決了「網路呼叫、限流、熔斷和監控」等問題，但大多數框架和開源軟體對原有業務是侵入式的，也就是需要在業務服務程式中整合相關的「服務治理」元件。
Service Mesh之於微服務，就像TCP/IP之於網際網路，TCP/IP為網路通訊提供了面向連線的、可靠的、基於位元組流的基礎通訊功能，你不再需要關心底層的重傳、校驗、流量控制、擁塞控制。
用了Service Mesh你也不必去操心「服務治理」的細節，不需要對服務做特殊的改造，所有業務之外的功能都由Service Mesh幫你去做了。它就像一個輕量級網路代理 對應用程式來說是透明，所有應用程式間的流量都會通過它，所以對應用程式流量的控制都可以在 serivce mesh 中實現 。
寫在最後
在IT世界沒有什麼技術是永不過時的，微服務架構的演進就是一個例子，從單體程式到微服務架構，再到service mesh架構，我不知道下一個技術迭代點是什麼時候，但我知道微服務架構肯定還會更新，IT人更應該建立終身學習習慣。
當然更重要的是擁有對技術的熱情，熱於擁抱變化、接受新技術，當我看到新技術我是興奮的，內心os是厲害了，還能這麼玩！，希望你也有這般熱情，而不僅僅是面向工資程式設計，生活會有趣很多。
老規矩。感謝各位的閱讀，文章的目的是分享對知識的理解，技術類文章我都會反覆求證以求最大程度保證準確性，若文中出現明顯紕漏也歡迎指出，我們一起在探討中學習。
「原創不易，看到這裡動動手指，各位的「三連」是對我持續創作的最大支援，我們下篇文章再見。」
可以微信搜尋公眾號「 後端技術學堂 」回覆「資料」「1024」有我給你準備的各種程式設計學習資料。文章每週持續更新，我們下期見！
reference
https://www.cnblogs.com/Zachary-Fan/p/service_manage_discovery.html
https://www.zhihu.com/question/56125281
http://dockone.io/article/3687
https://www.infoq.cn/article/micro-service-technology-stack
https://segmentfault.com/a/1190000010224335
https://book.douban.com/subject/26772677/
https://jimmysong.io/blog/what-is-a-service-mesh/
https://github.com/weibocom/motan/wiki/zh_userguide