單體式應(yīng)用程序

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

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

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

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

單體應(yīng)用程序的缺點

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

單體架構(gòu)

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

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

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

微服務(wù)

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

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

[[325601]]

舉例

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

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

微服務(wù)架構(gòu)

微服務(wù)與SOA

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

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

這些問題在微服務(wù)框架中得到很好的解決，你可以認(rèn)為微服務(wù)架構(gòu)是SOA的一種特定方法。

微服務(wù)架構(gòu)

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

微服務(wù)優(yōu)點

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

技術(shù)異構(gòu)性

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

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

隔離性

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

可擴(kuò)展性

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

簡化部署

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

易優(yōu)化

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

微服務(wù)缺點

我們上面一直在強(qiáng)調(diào)微服務(wù)的好處，但是，微服務(wù)架構(gòu)不是萬能的，并不能解決所有問題，其實這也是微服務(wù)把單體應(yīng)用拆分成很多小的分布式服務(wù)導(dǎo)致的，所謂人多手雜，服務(wù)多起來管理的不好各種問題就來了。

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

服務(wù)注冊與發(fā)現(xiàn)

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

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

服務(wù)發(fā)現(xiàn)

服務(wù)監(jiān)控

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

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

服務(wù)容錯

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

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

服務(wù)安全

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

服務(wù)治理

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

[[325603]]

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

微服務(wù)框架

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

Tars

騰訊內(nèi)部使用的微服務(wù)架構(gòu) TAF（Total Application Framework）多年的實踐成果總結(jié)而成的開源項目。僅支持 C++ 語言，目前在騰訊內(nèi)部應(yīng)用也非常廣泛。2017 年對外開源，僅支持 C++ 語言。

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

TARS架構(gòu)圖|來源github.com/TarsCloud

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

Dubbo

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

官網(wǎng)：http://dubbo.apache.org/zh-cn/

Dubbo架構(gòu)圖|圖片來源dubbo.apache.org

Motan

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

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

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

gRPC

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

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

gRPC架構(gòu)圖|圖片來源www.grpc.io

thrift

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

thrift架構(gòu) | 圖片來源wikimedia

微服務(wù)框架和RPC

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

什么是RPC

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

兩者關(guān)系

RPC和微服務(wù)框架的關(guān)系。「微服務(wù)框架」一般都包含了RPC的實現(xiàn)和一系列「服務(wù)治理」能力，是一套軟件開發(fā)框架。我們可以基于這個框架之上實現(xiàn)自己的微服務(wù)，方便的利用微服務(wù)框架提供的「服務(wù)治理」能力和RPC能力，所以微服務(wù)框架也被有些人稱作RPC框架。

下一代微服務(wù)架構(gòu)

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

特點

Service Mesh 有如下幾個特點：

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

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

Why Service Mesh

為什么現(xiàn)有微服務(wù)架構(gòu)已經(jīng)解決的問題還要用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é)一下：隨著微服務(wù)的增多復(fù)雜程度也增加，管理變得更加困難，微服務(wù)架構(gòu)雖然解決了「網(wǎng)絡(luò)調(diào)用、限流、熔斷和監(jiān)控」等問題，但大多數(shù)框架和開源軟件對原有業(yè)務(wù)是侵入式的，也就是需要在業(yè)務(wù)服務(wù)程序中集成相關(guān)的「服務(wù)治理」組件。

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

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

Service Mesh架構(gòu)|圖片來自：Pattern: Service Mesh

寫在最后

在IT世界沒有什么技術(shù)是永不過時的，微服務(wù)架構(gòu)的演進(jìn)就是一個例子，從單體程序到微服務(wù)架構(gòu)，再到service mesh架構(gòu)，我不知道下一個技術(shù)迭代點是什么時候，但可以肯定微服務(wù)架構(gòu)還會演進(jìn)，IT人更應(yīng)該建立終身學(xué)習(xí)的習(xí)慣。

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

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