單體式應用程序

與微服務相對的另一個概念是傳統(tǒng)的「單體式應用程序」( Monolithic application )，單體式應用內部包含了所有需要的服務。而且各個服務功能模塊有很強的耦合性，也就是相互依賴彼此，很難拆分和擴容。

在座的各位都寫過單體程序，給大家舉個栗子，剛開始寫代碼你寫helloworld 程序就是單體程序，一個程序包含所有功能，雖然helloworld 功能很簡單。

單體應用程序的優(yōu)點

•  開發(fā)簡潔，功能都在單個程序內部，便于軟件設計和開發(fā)規(guī)劃。
•  容易部署，程序單一不存在分布式集群的復雜部署環(huán)境，降低了部署難度。
•  容易測試，沒有各種復雜的服務調用關系，都是內部調用方便測試。

單體應用程序的缺點

單體程序的缺點一開始不是特別明顯，項目剛開始需求少，業(yè)務邏輯簡單，寫代碼一時爽，一直爽。噩夢從業(yè)務迭代更新，系統(tǒng)日益龐大開始，前期的爽沒有了，取而代之的是軟件維護和迭代更新的無盡痛苦。

單體架構

由于單體式應用程序就像一個大型容器一樣，里面放置了許多服務，且他們都是密不可分的，這導致應用程序在擴展時必須以「應用程序」為單位。

當里面有個業(yè)務模塊負載過高時，并不能夠單獨擴展該服務，必須擴展整個應用程序（就是這么霸道），這可能導致額外的資源浪費。

此外，單體式應用程序由于服務之間的緊密度、相依性過高，這將導致測試、升級有所困難，且開發(fā)曲線有可能會在后期大幅度地上升，令開發(fā)不易。相較之下「微服務架構」能夠解決這個問題。

微服務

微服務 (Microservices) 就是一些協同工作小而自治的服務。

    ❝    2014年，Martin Fowler 與 James Lewis 共同提出了微服務的概念，定義了微服務是由以單一應用程序構成的小服務，自己擁有自己的行程與輕量化處理，服務依業(yè)務功能設計，以全自動的方式部署，與其他服務使用 HTTP API 通信。同時服務會使用最小的規(guī)模的集中管理 (例如 Docker) 能力，服務可以用不同的編程語言與數據庫等組件實現 。「維基百科」    ❞

[[325601]]

舉例

還是拿前面的 helloworld 程序來舉栗子，想象一下你是 helloworld 公司的 CTO（老板還缺人嗎？會寫代碼的那種），假設你們公司的 helloworld 業(yè)務遍布全球，需要編寫不同語種的 helloworld 版本，分別輸出英語、日語、法語、俄語...現在世界有6000多種語言（奇怪的知識又增加了）。

有人會說這還不簡單我用switch case語句就完事了，同學，不要較真我就是舉個例子，現實中的業(yè)務比 helloworld 復雜多了。好了，我們姑且認為按語言輸出是個龐大復雜的工作，這時候就可以用微服務架構了，架構圖如下：

微服務架構

微服務與SOA

「面向服務的體系結構」 SOA (Service-Oriented Architecture) 聽起來和微服務很像，但 SOA 早期均使用了總線模式，這種總線模式是與某種技術棧強綁定的，比如：J2EE。這導致很多企業(yè)的遺留系統(tǒng)很難對接，切換時間太長，成本太高，新系統(tǒng)穩(wěn)定性的收斂也需要一些時間，最終 SOA 看起來很美，但卻成為了企業(yè)級奢侈品，中小公司都望而生畏。

此外，實施SOA時會遇到很多問題，比如通信協議（例如SOAP)的選擇、第三方中間件如何選擇、服務粒度如何確定等，目前也存在一些關于如何劃分系統(tǒng)的指導性原則，但其中有很多都是錯誤的。SOA并沒有告訴你如何劃分單體應用成微服務，所以在實施SOA時會遇到很多問題。

這些問題在微服務框架中得到很好的解決，你可以認為微服務架構是SOA的一種特定方法。

微服務架構

合久必分，鑒于「單體應用程序」有上述的缺點，單個應用程序被劃分成各種小的、互相連接的微服務，一個微服務完成一個比較單一的功能，相互之間保持獨立和解耦合，這就是微服務架構。

微服務優(yōu)點

相對于單體服務，微服務有很多優(yōu)點，這里列舉幾個主要的好處

技術異構性

不同服務內部的開發(fā)技術可以不一致，你可以用java來開發(fā)helloworld服務A，用golang來開發(fā)helloworld服務B，大家再也不用為哪種語言是世界上最好的語言而爭論不休。

為不同的服務選擇最適合該服務的技術，系統(tǒng)中不同部分也可以使用不同的存儲技術，比如A服務可以選擇redis存儲，B服務你可以選擇用MySQL存儲，這都是允許的，你的服務你做主。

隔離性

一個服務不可用不會導致另一個服務也癱瘓，因為各個服務是相互獨立和自治的系統(tǒng)。這在單體應用程序中是做不到的，單體應用程序中某個模塊癱瘓，必將導致整個系統(tǒng)不可用，當然，單體程序也可以在不同機器上部署同樣的程序來實現備份，不過，同樣存在上面說的資源浪費問題。

可擴展性

龐大的單體服務如果出現性能瓶頸只能對軟件整體進行擴展，可能真正影響性能的只是其中一個很小的模塊，我們也不得不付出升級整個應用的代價。這在微服務架構中得到了改善，你可以只對那些影響性能的服務做擴展升級，這樣對癥下藥的效果是很好的。

簡化部署

如果你的服務是一個超大的單體服務，有幾百萬行代碼，即使修改了幾行代碼也要重新編譯整個應用，這顯然是非常繁瑣的，而且軟件變更帶來的不確定性非常高，軟件部署的影響也非常大。在微服務架構中，各個服務的部署是獨立的，如果真出了問題也只是影響單個服務，可以快速回滾版本解決。

易優(yōu)化

微服務架構中單個服務的代碼量不會很大，這樣當你需要重構或者優(yōu)化這部分服務的時候，就會容易很多，畢竟，代碼量越少意味著代碼改動帶來的影響越可控。

微服務缺點

我們上面一直在強調微服務的好處，但是，微服務架構不是萬能的，并不能解決所有問題，其實這也是微服務把單體應用拆分成很多小的分布式服務導致的，所謂人多手雜，服務多起來管理的不好各種問題就來了。

為了解決微服務的缺點，前輩們提出了下面這些概念。

服務注冊與發(fā)現

微服務之間相互調用完成整體業(yè)務功能，如何在眾多微服務中找到正確的目標服務地址，這就是所謂「服務發(fā)現」功能。

常用的做法是服務提供方啟動的時候把自己的地址上報給「服務注冊中心」，這就是「服務注冊」。服務調用方「訂閱」服務變更「通知」，動態(tài)的接收服務注冊中心推送的服務地址列表，以后想找哪個服務直接發(fā)給他就可以。

服務發(fā)現

服務監(jiān)控

單體程序的監(jiān)控運維還好說，大型微服務架構的服務運維是一大挑戰(zhàn)。服務運維人員需要實時的掌握服務運行中的各種狀態(tài)，最好有個控制面板能看到服務的內存使用率、調用次數、健康狀況等信息。

這就需要我們有一套完備的服務監(jiān)控體系，包括拓撲關系、監(jiān)控（Metrics）、日志監(jiān)控（Logging）、調用追蹤（Trace）、告警通知、健康檢查等，防患于未然。

服務容錯

任何服務都不能保證100%不出問題，生產環(huán)境復雜多變，服務運行過程中不可避免的發(fā)生各種故障（宕機、過載等等），工程師能夠做的是在故障發(fā)生時盡可能降低影響范圍、盡快恢復正常服務。

聰明的程序員引入了「熔斷、隔離、限流和降級、超時機制」等「服務容錯」機制來保證服務持續(xù)可用性。

服務安全

有些服務的敏感數據存在安全問題，「服務安全」就是對敏感服務采用安全鑒權機制，對服務的訪問需要進行相應的身份驗證和授權，防止數據泄露的風險，安全是一個長久的話題，在微服務中也有很多工作要做。

服務治理

說到「治理」一般都是有問題才需要治理，我們平常說環(huán)境治理、污染治理一個意思，微服務架構中的微服務越來越多，上面說的那些問題就更加顯現，為了解決上面微服務架構缺陷「服務治理」就出現了。

[[325603]]

微服務的那些問題都要公司技術團隊自己解決的話，如果不是大型公司有成熟的技術團隊，估計會很頭大。幸好，有巨人的肩膀可以借給我們站上去，通過引入「微服務框架」來幫助我們完成服務治理。

微服務框架

介紹一些業(yè)界比較成熟的微服務框架。

Tars

騰訊內部使用的微服務架構 TAF（Total Application Framework）多年的實踐成果總結而成的開源項目。僅支持 C++ 語言，目前在騰訊內部應用也非常廣泛。2017 年對外開源，僅支持 C++ 語言。

源碼：https://github.com/TarsCloud/Tars/

TARS架構圖|來源github.com/TarsCloud

本命鵝廠 TARS 框架詳細介紹 PPT 已下載，不想自己麻煩去找的同學，在我公眾號「后端技術學堂」回復「tars」獲取。

Dubbo

是阿里巴巴公司開源的一個Java高性能優(yōu)秀的服務框架，使得應用可通過高性能的 RPC 實現服務的輸出和輸入功能，可以和 Spring框架無縫集成。Apache Dubbo |ˈdʌbəʊ| 是一款高性能、輕量級的開源Java RPC框架，它提供了三大核心能力：面向接口的遠程方法調用，智能容錯和負載均衡，以及服務自動注冊和發(fā)現 。2011 年末對外開源，僅支持 Java 語言。

官網：http://dubbo.apache.org/zh-cn/

Dubbo架構圖|圖片來源dubbo.apache.org

Motan

是新浪微博開源的一個Java 框架。Motan 在微博平臺中已經廣泛應用，每天為數百個服務完成近千億次的調用。于 2016 年對外開源，僅支持 Java 語言。

官方指南：https://github.com/weibocom/motan/wiki/zh_userguide

Motan框架|圖片來源github.com/weibocom/motan

gRPC

是Google開發(fā)的高性能、通用的開源RPC框架，其由Google主要面向移動應用開發(fā)并基于HTTP/2協議標準而設計，基于ProtoBuf(Protocol Buffers)序列化協議開發(fā)。本身它不是分布式的，所以要實現上面的框架的功能需要進一步的開發(fā)。2015 年對外開源的跨語言 RPC 框架，支持多種語言。

中文教程：https://doc.oschina.net/grpc?t=58008

gRPC架構圖|圖片來源www.grpc.io

thrift

最初是由 Facebook 開發(fā)的內部系統(tǒng)跨語言的高性能 RPC 框架，2007 年貢獻給了 Apache 基金，成為 Apache 開源項目之一， 跟 gRPC 一樣，Thrift 也有一套自己的接口定義語言 IDL，可以通過代碼生成器，生成各種編程語言的 Client 端和 Server 端的 SDK 代碼，支持多種語言。

thrift架構 | 圖片來源wikimedia

微服務框架和RPC

很多人對這兩個概念有點混淆，微服務框架上面我們說過了，我們再來看下RPC的概念。

什么是RPC

RPC (Remote Procedure Call)遠程過程調用是一個計算機通信協議。我們一般的程序調用是本地程序內部的調用，RPC允許你像調用本地函數一樣去調用另一個程序的函數，這中間會涉及網絡通信和進程間通信，但你無需知道實現細節(jié)，RPC框架為你屏蔽了底層實現。RPC是一種服務器-客戶端（Client/Server）模式，經典實現是一個通過「發(fā)送請求-接受回應」進行信息交互的系統(tǒng)。

兩者關系

RPC和微服務框架的關系?！肝⒎湛蚣堋挂话愣及薘PC的實現和一系列「服務治理」能力，是一套軟件開發(fā)框架。我們可以基于這個框架之上實現自己的微服務，方便的利用微服務框架提供的「服務治理」能力和RPC能力，所以微服務框架也被有些人稱作RPC框架。

下一代微服務架構

Service Mesh（服務網格）被認為是下一代微服務架構，Service Mesh并沒有給我們帶來新的功能，它是用于解決其他工具已經解決過的服務網絡調用、限流、熔斷和監(jiān)控等問題，只不過這次是在Cloud Native 的 kubernetes 環(huán)境下的實現。

特點

Service Mesh 有如下幾個特點：

•  應用程序間通訊的中間層
•  輕量級網絡代理
•  應用程序無感知
•  解耦應用程序的重試/超時、監(jiān)控、追蹤和服務發(fā)現

目前兩款流行的 Service Mesh 開源軟件 [Istio](https://istio.io/) 和 [Linkerd](https://linkerd.io/)都可以直接在kubernetes 中集成，其中Linkerd已經成為云原生計算基金會 CNCF (Cloud Native Computing Foundation) 成員。

Why Service Mesh

為什么現有微服務架構已經解決的問題還要用Service Mesh呢？這個問題問的好。

[[325604]]

回答問題之前，先看下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.  **    ❞

試著總結一下：隨著微服務的增多復雜程度也增加，管理變得更加困難，微服務架構雖然解決了「網絡調用、限流、熔斷和監(jiān)控」等問題，但大多數框架和開源軟件對原有業(yè)務是侵入式的，也就是需要在業(yè)務服務程序中集成相關的「服務治理」組件。

Service Mesh之于微服務，就像TCP/IP之于互聯網，TCP/IP為網絡通信提供了面向連接的、可靠的、基于字節(jié)流的基礎通信功能，你不再需要關心底層的重傳、校驗、流量控制、擁塞控制。

用了Service Mesh你也不必去操心「服務治理」的細節(jié)，不需要對服務做特殊的改造，所有業(yè)務之外的功能都由Service Mesh幫你去做了。它就像一個輕量級網絡代理 對應用程序來說是透明，所有應用程序間的流量都會通過它，所以對應用程序流量的控制都可以在 serivce mesh 中實現 。

Service Mesh架構|圖片來自：Pattern: Service Mesh

寫在最后

在IT世界沒有什么技術是永不過時的，微服務架構的演進就是一個例子，從單體程序到微服務架構，再到service mesh架構，我不知道下一個技術迭代點是什么時候，但可以肯定微服務架構還會演進，IT人更應該建立終身學習的習慣。

當然更重要的是擁有對技術的熱情，熱于擁抱變化、接受新技術，當看到新技術我是興奮的，內心os是厲害了，還能這么玩！，希望你也有這樣的熱情，而不僅僅是面向工資編程，這樣生活會更有樂趣。

老規(guī)矩。感謝各位的閱讀，文章的目的是分享對知識的理解，技術類文章我都會反復求證以求最大程度保證準確性，若文中出現明顯紕漏也歡迎指出，我們一起在探討中學習。