[[336304]]

博客網(wǎng)址：httpswww.itzhai.com 

有不少朋友或同事都問過我這個問題：為什么我們要搞微服務架構，一個項目把代碼從頭擼到尾不是很方便嗎，開發(fā)更快速，部署也容易。而且一提起微服務，涉及的技術就一大堆，好像幾輩子也學不完。

 

怎么解答這個問題呢?我想還是通過架構的發(fā)展變遷史來說起，為什么會出現(xiàn)現(xiàn)在的各種架構。只有從整體上了解了架構的脈絡，我們才好更加全方位的評估一個架構。為此，我們有理由來梳理一下架構發(fā)展的來龍去脈，究竟為何會出現(xiàn)微服務，主要解決什么問題。微服務架構是最先進的架構嗎?

本文我們來探索一下架構的變遷。以及從Java工程師的角度來看技術的發(fā)展，了解我們在討論微服務的時候，都會涉及哪些技術。微服務的下一步將如何發(fā)展。閱讀完本文，你將了解到：

• 軟件架構的發(fā)展史
• SOA架構與MSA架構的區(qū)別
• 微服務架構核心關注的問題是什么
• 如何做微服務架構的技術選型
• 目前架構正在朝著什么方向發(fā)展
• 架構升級與業(yè)務發(fā)展的關系，一定要用最前衛(wèi)的架構技術嗎?什么樣的架構才是好的架構
• 微服務的難點是什么，這里主要留給大家思考，會在后續(xù)文章中進一步講解

首先我們還是回顧一下架構的整體發(fā)展史。

0、架構發(fā)展史

架構也是隨著其缺陷不斷演變而來的，下面是粗略的架構演變史：

 

70~80s：集中式(大型機)

上世紀70年代和80年代，大型機是計算機的工作方式。

問題所在：最初的大型計算機使用打孔卡，并且大多數(shù)計算都在批處理過程中進行。沒有在線處理，并且延遲為100%，因為沒有實時處理。

架構演變：隨著在線處理和用戶界面終端的推出，大型機范式發(fā)生了一些變化。

90s：CS架構(分布式)

客戶端/服務器體系結構將大多數(shù)邏輯放在服務器端，并將某些處理放在客戶端上。

問題所在：在該體系結構的最初幾年中，開發(fā)社區(qū)仍在使用與大型機開發(fā)相同的過程，采用單層原則來為客戶端/服務器編寫軟件，從而產(chǎn)生了諸如意大利面條代碼和Blob之類的反模式。

架構演變：引入了一項稱為面向對象程序設計(OOP)的重大改進;

客戶/服務器模型基于三層體系結構，包括展示層，業(yè)務邏輯層和數(shù)據(jù)層。但是大多數(shù)應用程序是使用兩層模型編寫的，胖客戶端將所有展示、業(yè)務和數(shù)據(jù)訪問邏輯封裝在一起，直接訪問數(shù)據(jù)庫。盡管業(yè)界已經(jīng)開始討論將展示與業(yè)務與數(shù)據(jù)訪問分開的必要性，但是這種做法直到基于Internet的應用程序問世才真正變得至關重要。

2000：去中心化(Internet)

在90年代中期，互聯(lián)網(wǎng)革命發(fā)生了，Web瀏覽器成為客戶端軟件，而Web和應用程序服務器托管所有處理和邏輯。

問題所在：開發(fā)人員仍在將軟件設計為緊密耦合的設計，從而導致混亂和其他反模式。

架構演變：作為解決辦法，業(yè)界提出了三層體系結構和實踐，例如領域驅動設計(DDD)，企業(yè)集成模式(EIP)，SOA和松耦合技術。

2006：云托管

21世紀前10年見證了云計算作為服務托管形式的重大改變。應用程序需要的一些能力，云計算平臺托管了基礎功能：分布式計算、網(wǎng)絡、存儲以及計算等，與傳統(tǒng)的基礎架構相比，云托管的方式能更好的控制成本。

問題所在：它誘使將尚未設計用于彈性分布式架構的遺留應用程序直接遷移和遷移到云中，從而產(chǎn)生了單體地獄這種反模式。

遷移到云還給行業(yè)帶來了管理第三方庫和技術上的應用程序依賴項的挑戰(zhàn)。沒有足夠的標準來選擇第三方工具，我們開始看到一些依賴地獄。另外服務擴容也是一個問題。

架構演變：了應對這些挑戰(zhàn)，業(yè)界提出了新的架構模式，例如微服務和12要素應用程序[8]，彈性服務。

2014：微服務

諸如DDD和EIP之類的軟件設計自2003年左右就已經(jīng)開始實踐起來了，此時一些團隊將應用程序開發(fā)為模塊化服務，但是傳統(tǒng)的基礎結構(如Java應用程序的重量級J2EE應用程序服務器和.NET應用程序的IIS)對模塊化部署并沒有幫助。

隨著云托管的出現(xiàn)，尤其是諸如Heroku和Cloud Foundry之類的PaaS產(chǎn)品的出現(xiàn)，開發(fā)人員社區(qū)擁有了真正的模塊化部署和可擴展業(yè)務應用所需的一切。這引起了微服務的發(fā)展。微服務為打造細粒度、可重用的功能和非功能服務提供了可能性。

問題所在：原本的單體系統(tǒng)、未被設計為微服務的傳統(tǒng)應用程序開始被蠶食，試圖迫使它們進入微服務體系結構，由于拆解的不當，從而導致了被稱為微單體的反模式。單體和微服務是兩種不同的模式，后者并不總是可以替代前者。如果我們不小心的話，最終可能會創(chuàng)建緊密耦合，混雜的微服務。微服務劇增的另一個不希望出現(xiàn)的副作用是所謂的“死亡星球”的反模式。

架構演變：諸如服務網(wǎng)格，邊車，服務編排和容器之類的新興架構模式可以有效地防御基于云的世界中的瀆職行為。隨著云平臺的出現(xiàn)，特別是像Kubernetes這樣的容器編排技術，服務網(wǎng)格已經(jīng)引起了人們的關注。服務網(wǎng)格是應用程序服務之間的橋梁，可添加其他功能，例如流量控制，服務發(fā)現(xiàn)，負載平衡，彈性，可觀察性，安全性等。

幾種架構反模式[3]說明

• 單體地獄[4]：
• 好處：早期開發(fā)簡單、易于對程序做重大更改、直接測試、直接部署、易于擴展;
• 缺點：隨著業(yè)務增長，暴露問題：復雜度高、開發(fā)效率低下、從提交到部署耗時長、伸縮性差、技術棧過時難以升級、缺乏故障隔離導致一個小功能可能會影響整個系統(tǒng);
• 微單體[5]：
• 一種非彈性和不可擴展的微服務系統(tǒng)，即所謂的微單體;單體和微服務是兩種不同的模式，后者并不總是可以替代前者。如果我們不小心的話，最終可能會創(chuàng)建緊密耦合，混雜的微服務(微單體)。我們應該根據(jù)應用程序功能的業(yè)務和可伸縮性要求做抉擇;
• 積木塔：單體應用程序類似于積木塔：您永遠不知道發(fā)生故障時哪塊磚可能會出問題。由于該應用程序的所有模塊都在同一進程中運行，因此，如果某個模塊受到錯誤的影響，則會降低整個過程，從而影響整個應用程序。在完成故障排除之前，您可能會失去數(shù)百甚至數(shù)千個商機;
• 科學怪人[7]：科學怪人是一部著名的美國電影，講述了一個天才科學家創(chuàng)造了一個怪物最終被其毀滅的故事。Istio 團隊為以它來自嘲。Istio 本想扮演上帝一般的角色(統(tǒng)一 Service Mesh 江湖，成為微服務架構的事實標準)，卻因為過度設計與現(xiàn)實脫離，成為了一個怪獸(monster)。因此，重構的第一階段，就是從肢解怪獸開始，把微服務架構重新改回了單體架構，但是內部模塊劃分還是很清晰的;
• 方輪：重新發(fā)明方的輪子，已經(jīng)有了一個很好的方案，又搞一個方案來替代它;
• 死亡星球[6]：
• 在服務交互和服務到服務的安全性(身份驗證和授權)方面，如果沒有治理模型，微服務的泛濫通常會導致任何服務都可以隨意調用任何其他服務的情況。就有可能出現(xiàn)想死亡星球那樣的調用視圖，異常復雜。諸如服務網(wǎng)格，邊車，服務編排和容器之類的新興架構模式可以有效地防御基于云的世界中的瀆職行為;
• 意大利面條式的設計：面條之間互相纏繞在一起，很難梳理清楚它們之間的關系。意大利面式的設計很形象的說明了軟件開發(fā)中的這種現(xiàn)象：系統(tǒng)很難維護，各種功能邏輯纏繞在一起，沒有清晰的模塊和層次關系;
• The Blob：表示的是一個類型具有了過多的職能，導致其過于龐大，最后使代碼難以維護。

架構演變步驟

一般的，每一個架構的出現(xiàn)，不是一蹴而就的，都會經(jīng)歷以下幾個過程：

• 引入新模型;
• 最佳架構實踐未知或者不存在;
• 反模式，技術債務劇增;
• 行業(yè)開發(fā)新的體系結構以適應新的范式;
• 團隊研究并采用新的標準架構;

下面我們將于Java工程師的角度來觀察架構的大致發(fā)展史。

1、第一階段：學好SSH框架，走遍天下都不怕

早期，大部分IT系統(tǒng)都是單體系統(tǒng)，例如傳統(tǒng)的SSH架構，此時前后端也沒有分離，UI組件也包含在了控制層：

 

這一時期服務的對象主要是傳統(tǒng)企業(yè)，并發(fā)不高，主要是業(yè)務開發(fā)，這種開發(fā)方式很方便。當年剛畢業(yè)的時候我還和同學在納悶，那些互聯(lián)網(wǎng)公司是不是也用SSH框架。

其實真實情況呢?隨著互聯(lián)網(wǎng)企業(yè)的崛起，DAU持續(xù)增長，業(yè)務并發(fā)量也逐漸增高，SSH架構單JVM部署這種簡單的方式并不能滿足高并發(fā)場景，我們需要一種能夠支持給系統(tǒng)進行水平擴展的架構。

2、第二階段：分布式系統(tǒng)

為了方便給系統(tǒng)擴容，以及增加系統(tǒng)的復用性，出現(xiàn)分布式系統(tǒng)。

另一方面，系統(tǒng)模塊快速膨脹，為了降低系統(tǒng)內部的復雜度，于是對系統(tǒng)模塊進行拆解，分布到不同的系統(tǒng)中，降低模塊耦合，加快迭代速度。

業(yè)界提出了三層體系結構和實踐，例如域驅動設計(DDD)，企業(yè)集成模式(EIP)，SOA和松耦合技術。

3、SOA

早期的分布式系統(tǒng)是基于面向服務的架構SOA。SOA是微服務的前身，主要是為了擺脫單體應用的問題，達到以下效果：

• 充分利用現(xiàn)有的基礎設施;
• SOA體系結構依賴于消息傳遞(AMQP，MSMQ)和SOAP作為主要的遠程訪問協(xié)議。
• 快速響應業(yè)務變化;

根據(jù)一位印度小哥的介紹，我畫了下面這張SOA的架構圖：

 

也就是說，異構系統(tǒng)，也可以通過消息中間件的協(xié)議轉換進行相互調用。一般這個消息中間件通常是用ESB企業(yè)總線實現(xiàn)的。ESB 是傳統(tǒng)中間件技術與XML、Web服務等技術相互結合的產(chǎn)物，消除了不同應用之間的技術差異，讓不同的應用服務器協(xié)調運作，實現(xiàn)了不同服務之間的通信與整合。不同公司提供了不同的ESB中間件實現(xiàn)。

但是其表現(xiàn)并不佳，主要是其太重了，主要體現(xiàn)在：

• SOA更強調系統(tǒng)集成的規(guī)范與便利性，對業(yè)務服務本身沒有過多要求，一般服務拆分粒度不夠細，模塊間仍然會有比較大的耦合，迭代困難;
• SOA服務之間的通信相對比較復雜，重量級。WebService中常用的SOAP通信協(xié)議，通常使用XML格式進行通信，數(shù)據(jù)冗余，協(xié)議過重;EBS通過總線隱藏內部復雜性，其中心化管理模式，系統(tǒng)變更，對系統(tǒng)的影響范圍會擴大。
• 在SOA模型下通常只有一個數(shù)據(jù)庫，限制了系統(tǒng)的擴展性;
• 服務化管理和治理設施不完善;

后來逐漸演變?yōu)榱爽F(xiàn)在的MSA(Micro-Service Archeticture 微服務架構)，從而實現(xiàn)了更加松耦合以及更加靈活的系統(tǒng)。

4、微服務(MSA)

微服務使用各個子服務控制模塊的思想代替SOA中的總線。服務控制模塊通常至少包含：服務注冊與發(fā)布、路由、代理。

微服務與SOA的對比

• 目的：
• SOA強調異構服務之間的協(xié)作和契約，強調有效集成，最大化應用程序服務的可重用性;
• 微服務的目的是拆分解耦應用，專注去耦合，讓不同不同的業(yè)務團隊服務不同的微服務，專人專事，縮小迭代影響范圍，讓微服務更容易進行水平擴展;微服務遵循單一職責，是一種克服系統(tǒng)復雜性的分解技術。如果你覺得你的某個微服務很復雜，那么考慮看看是否拆分的不夠細?也正是因為這種拆分，本質上增強了安全性和故障隔離;
• 部署方式：
• SOA服務不多，一般打包后直接通過war形式部署到服務器;
• 微服務由于數(shù)量眾多，需要實現(xiàn)快速擴容和縮容，一般借助容器化技術來實現(xiàn)部署，微服務之間獨立部署，互不影響;
• 服務粒度：
• SOA對粒度無要求，通常是粗粒度的，更強調的是接口的規(guī)范化;
• 微服務提倡進行細粒度的拆分，保證服務職責的單一。

 

4.1、微服務的優(yōu)勢

4.1.1、方便擴容與保證服務可伸縮性

正是因為微服務的拆解，讓我們增加了系統(tǒng)的安全性和故障隔離，可以讓我們針對不同的服務，實施不同的擴容和存儲技術。

例如，一些微服務可能使用關系數(shù)據(jù)庫，而另一些可能使用NoSQL數(shù)據(jù)庫甚至掛載的文件系統(tǒng)。以這種方式構建應用程序增加了團隊構建應用程序的可伸縮性。

4.1.2、降低耦合，利于團隊協(xié)作與版本快速更新

在SOA系統(tǒng)，或者是傳統(tǒng)的單體系統(tǒng)中，使用一個項目的時候，通常會有一個大團隊的人在同一個項目的同一個分支上工作，并且總是互相干擾，出現(xiàn)各種代碼沖突，隨著代碼增長，開發(fā)速度會呈現(xiàn)指數(shù)級增長。這是我們以前遇到過的問題，特別頭疼，后來花了很大的精力對系統(tǒng)做了服務化改造拆分。

當然主導這個服務化改造也是需要申請不少資源的，即使沒有新的業(yè)務上線。為了讓老板認為我們正在做的改造是存在價值的，當時還寫了改造前后的各種利弊對比。這是很重要的，我們總不能無故的去改造一個運行良好的系統(tǒng)。

有了微服務架構，應用程序由小型分散的開發(fā)團隊構建，這些團隊獨立地工作和更改微服務。

4.1.3、服務自治

這使得測試和升級服務以及隨時間增加功能變得更加容易。

最終，如果一個微服務在規(guī)模和功能上增長，它可以被分解并分成多個微服務，從而保持微服務的小型、可管理和自治。

4.1.4、讓項目保持技術多樣性

最后，采用微服務體系結構允許使用最適合其開發(fā)的任何語言和技術堆棧來編寫單個服務。并沒有嚴格的限制所有的微服務都必須使用相同的技術來開發(fā)，只要它們都通過相同的輕量級協(xié)議(如HTTP和消息)進行通信，并且數(shù)據(jù)結構以相同的格式進行序列化(JSON是最流行的選擇)。

微服務的特點是:

• 輕量級的組件;
• 服務獨立的部署能力;
• 輕量級、粗粒度api;
• 輕量級的服務總線;
• 輕量級的數(shù)據(jù)存儲;

4.1.5、避免了單體系統(tǒng)開發(fā)效率低下的問題

單體系統(tǒng)要么是數(shù)據(jù)庫變得太大了，要么是代碼行太多了，更有可能的是，現(xiàn)在的開發(fā)人員不能快速地添加新特性。微服務體系結構避免了單體系統(tǒng)的缺陷，使用真實且可靠的分解技術來解決這些缺陷，并將重點放在敏捷開發(fā)和可替換性上，而不是可重用性上。

此外，與單體系統(tǒng)不同，微服務是一個可持續(xù)的體系結構，通過添加新的微服務來滿足快速變化的業(yè)務需求，而不是修改(和破壞)舊的服務。

4.2、微服務面臨的問題

沒有什么架構是免費的

盡管微服務有很多好處，但它并不是萬能的。微服務在減輕整體應用程序固有的許多問題的同時，也帶來了其他挑戰(zhàn)。與技術領域的任何事情一樣，總是需要在不同的體系結構和微服務之間進行權衡。

4.2.1、增加了運維的復雜度，以及維護微服務集群的復雜度

它所提供的敏捷性和開發(fā)速度是以增加操作復雜性為代價的，因為自然有更多的活動部件(或服務)—可能比單體應用還要多。

使用微服務架構可能會增加運維開銷。使用這種方法，您的部署可能需要大量資源。您可能需要更多的時間和精力來創(chuàng)建基礎架構。所有服務可能都需要群集以實現(xiàn)故障轉移和彈性。您的系統(tǒng)可能具有數(shù)十個單獨的組件，并且在您添加新功能時，它將變得越來越復雜。

您可能會得到一個由20或30個或更多服務組成的解決方案，而不是一個整體系統(tǒng)，每個服務都運行多個進程。

最佳實踐是，您應該通過DevOps自動化解決這些額外的工作開銷。

4.2.2、單體系統(tǒng)遷移到微服務比價困難

把單體系統(tǒng)遷移到微服務也是一個巨大的工作量。不推薦用微服務重寫系統(tǒng)，這不太現(xiàn)實，特別是單體系統(tǒng)業(yè)務比較復雜的時候。建議采用一種更漸進的方法，逐步地重構一個單體系統(tǒng)，逐漸地將它轉變成一個由微服務組成的“新”應用程序。隨著時間的推移，單體應用程序實現(xiàn)的功能數(shù)量會減少，直到完全消失或變成另一個微服務應用程序。最后，不要覺得有必要立即開始分解一切;花時間和工作在最合理的方式為你的團隊。

4.2.3、提高了開發(fā)的技術門檻

在開始實際的遷移過程之前，我們得思考權衡以下問題：可以肯定的是，具有微服務體系結構的系統(tǒng)提供了大量的好處，例如獨立部署、強大的子系統(tǒng)邊界和技術多樣性。

但是，因為微服務是一個分布式系統(tǒng)，它帶來了開發(fā)分布式應用程序相關的復雜性的代價，如：獨立的數(shù)據(jù)模型、微服務之間的彈性通信、最終一致性和操作復雜性等。開發(fā)和運行大規(guī)模的分布式服務也不是一件容易的事情。

在實際的把單體系統(tǒng)拆分為微服務的過程中，不建議用服務大小來衡量拆分效果，而是拆分的業(yè)務邊界，可以考慮使用DDD的方式去進行建模設計。DDD是我們架構師工具箱中用于標識和設計微服務的優(yōu)秀工具。

4.3、微服務技術體系

微服務需要關注的點很多，下面畫了一張圖來表述：

 

總的來說，微服務MSA架構需要以下技術點的支持：

• 配置管理;
• 服務發(fā)現(xiàn)和負載均衡;
• 彈性和容錯;
• API管理;
• 服務安全;
• 日志管理;
• Metrics監(jiān)控;
• 分布式調用鏈追蹤;
• 調度和發(fā)布;
• 自動伸縮和自愈;

除了技術相關的，組織結構和團隊文化也是很重要的。

下面是一般微服務涉及到的各種組件：

 

5、微服務技術選型

我們先來關注下微服務的各種技術棧的優(yōu)缺點。

5.1、Spring Cloud

為開發(fā)人員提供了用于構建MSA的工具，例如：配置中心、服務發(fā)現(xiàn)、斷路器、路由等。它是基于Java的Netflix OSS庫構建的。

關于如何使用Spring Cloud構建一個微服務架構，推薦您閱讀：Microservice Architectures With Spring Cloud and Docker：https://dzone.com/articles/microservice-architecture-with-spring-cloud-and-do，相關項目架構圖如下：

 

5.1.1、優(yōu)點

• Spring技術棧，快速上手，開箱即用：Spring平臺提供了統(tǒng)一編程模型，以及Spring Boot快速創(chuàng)建應用程序的功能，為開發(fā)人員提供了出色的微服務開發(fā)套件，僅僅需要很少的配置，就可以創(chuàng)建應用;
• 組件庫豐富;
• 不同Spring Cloud組件可以很好的集成工作，一切基于注釋驅動，易于開發(fā)，感覺就像是Java開發(fā)者的天堂。

5.1.2、缺點

• 僅限于Java。我們前面提到MSA架構的魅力在于能夠在需要時修改技術棧，庫甚至語言的。Spring Cloud則無法做到這一點。Netflix的Prana項目中使用了邊車模式，通過HTTP調用可以在系統(tǒng)中集成非JVM的應用。通過HTTP與Prana進行跨進程通信，使得用其他語言編寫的應用程序或Memcached、Spark和Hadoop等服務能夠利用Netflix OSS庫提供的特性，而不必為目標語言或平臺重新編寫庫;
• Java程序員承擔了太多的責任，服務發(fā)現(xiàn)、負載均衡、配置中心均需要單獨部署，而且我們要保證高可用，除了實現(xiàn)服務功能，我們還必須構建和管理一個微服務平臺;
• 不能覆蓋MSA整個生命周期：微服務平臺部分必備功能缺失，自動化部署、調度、資源管理、進程隔離、自我修復等仍然是一個問題。我們仍然需要引入Kubernetes或者Cloud Foundry來解決此類問題。

5.2、Dubbo

其實dubbo只是一個rpc框架，其架構如下(來源于官方網(wǎng)站^2)：

 

調用關系說明

1. 服務容器負責啟動，加載，運行服務提供者。
2. 服務提供者在啟動時，向注冊中心注冊自己提供的服務。
3. 服務消費者在啟動時，向注冊中心訂閱自己所需的服務。
4. 注冊中心返回服務提供者地址列表給消費者，如果有變更，注冊中心將基于長連接推送變更數(shù)據(jù)給消費者。
5. 服務消費者，從提供者地址列表中，基于軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
6. 服務消費者和提供者，在內存中累計調用次數(shù)和調用時間，定時每分鐘發(fā)送一次統(tǒng)計數(shù)據(jù)到監(jiān)控中心。

其提供了Metrics監(jiān)控，服務發(fā)現(xiàn)和負載均衡，rpc調用，其實不能算是一個MSA體系，不過后來阿里整合了Spring Cloud，推出了Spring Cloud Alibaba，作為微服務開發(fā)的一站式解決方案。其中包含了Dubbo Spring Cloud。

由于 Dubbo Spring Cloud 構建在原生的 Spring Cloud 之上，其服務治理方面的能力可認為是 Spring Cloud Plus，不僅完全覆蓋 Spring Cloud 原生特性，而且提供更為穩(wěn)定和成熟的實現(xiàn)：

• 服務限流降級：默認支持 WebServlet、WebFlux, OpenFeign、RestTemplate、Spring Cloud Gateway, Zuul, Dubbo 和 RocketMQ 限流降級功能的接入，可以在運行時通過控制臺實時修改限流降級規(guī)則，還支持查看限流降級 Metrics 監(jiān)控。
• 服務注冊與發(fā)現(xiàn)：適配 Spring Cloud 服務注冊與發(fā)現(xiàn)標準，默認集成了 Ribbon 的支持。
• 分布式配置管理：支持分布式系統(tǒng)中的外部化配置，配置更改時自動刷新。
• 消息驅動能力：基于 Spring Cloud Stream 為微服務應用構建消息驅動能力。
• 分布式事務：使用 @GlobalTransactional 注解， 高效并且對業(yè)務零侵入地解決分布式事務問題。。
• 阿里云對象存儲：阿里云提供的海量、安全、低成本、高可靠的云存儲服務。支持在任何應用、任何時間、任何地點存儲和訪問任意類型的數(shù)據(jù)。
• 分布式任務調度：提供秒級、精準、高可靠、高可用的定時(基于 Cron 表達式)任務調度服務。同時提供分布式的任務執(zhí)行模型，如網(wǎng)格任務。網(wǎng)格任務支持海量子任務均勻分配到所有 Worker(schedulerx-client)上執(zhí)行。
• 阿里云短信服務：覆蓋全球的短信服務，友好、高效、智能的互聯(lián)化通訊能力，幫助企業(yè)迅速搭建客戶觸達通道。

5.3、Kubernetes

Kubernetes是一個開源系統(tǒng)，用于應用程序自動化容器部署、擴展和管理。它支持多語言，并提供了用于配置，運行，擴展和管理分布式系統(tǒng)的原語。

優(yōu)點

多語言和通用容器管理平臺，能夠運行云原生和傳統(tǒng)容器化應用程序;

易于構建跨團隊的平臺：提供的服務(例如配置管理，服務發(fā)現(xiàn)，負載平衡，指標收集，日志聚合)可以通過多種語言來使用;

解決了更多MSA的問題：除了提供運行時服務外，Kubernetes還允許您置備環(huán)境、設置資源約束、RBAC、管理應用程序生命周期、啟用自動縮放和自我修復等;

社區(qū)活躍，技術發(fā)展迅猛;

缺點

具有通用化服務和原語的平臺，沒有針對特定語言或平臺進行優(yōu)化，上手比較困難;

不是以開發(fā)人員為中心的平臺，致力于打造具有DevOps意識的IT人員使用，手動安裝高可用的Kubernetes集群需要繁瑣的操作和配置;

是一個較新的平臺，仍然在發(fā)展，每個版本都會新增很多特性，新功能比較難跟上;但是其提供更多API是可擴展的，并且向后兼容;

下面列一個表格總結下：

 

5.4、MSA技術選型

Dubbo只是一個RPC框架，提供的功能不能覆蓋整個MSA生命周期。

Spring Cloud是開發(fā)人員友好的平臺，可快速上手。

而Kubernetes是DevOps友好的，具有陡峭的學習曲線，但提供了更多的微服務問題解決方案。

Spring Cloud在JVM內部非常強大，而Kubernetes在管理這些JVM方面非常強大。

 

根據(jù)以上對比，我們想要搭建一個完整的微服務體系架構，有很多技術可以選擇的。那么究竟應該如何選擇呢

下面是推薦技術選型方案：

• 如果是新團隊做技術選型，建議直接上Kubernetes，當然，你可以采用Spring Boot。為了提高內部服務調用的效率，可以整合dubbo，但是建議采用Kubernetes內置的服務發(fā)現(xiàn)和負載均衡，也就是引入的外部技術要最小化;
• 中小企業(yè)可能沒有人力成本去自建Kubernetes平臺，可以采用公有云;
• 盡量不要混搭，會增加維護成本;
• 針對歷史采用了Dubbo的項目，盡量遷移到Dubbo Spring Cloud完善其他組件。使用Dubbo Spring Cloud[1]，配合Kubernetes實現(xiàn)DevOps系統(tǒng)。內部調用通過Dubbo RPC進行，提高效率。

技術方案選型歸納如下：

 

6、關于架構選型

架構沒有好壞之分，只有最適合業(yè)務的架構，才是最好的。

如何選型

這里我舉個例子來說明架構選型是要跟業(yè)務匹配的。我們先來了解三種架構：

• 單體架構云：一個典型的單體應用就是將所有的業(yè)務場景的表示層、業(yè)務邏輯層和數(shù)據(jù)訪問層放在一個工程中，最終經(jīng)過編譯、打包，部署在一臺服務器上。
• 微服務架構：微服務是將一個大型復雜軟件應用由一個或多個微服務組成，系統(tǒng)中的各個微服務可被獨立部署，各個微服務之間是松耦合的。
• Serverless架構：無服務器架構是指大量依賴第三方BaaS(后端即服務)服務或暫存容器中運行的自定義代碼FaaS(函數(shù)即服務)的應用程序，函數(shù)是無服務器架構中抽象語言運行時的最小單位。Severless架構中，我們關注運行函數(shù)所需的時間，從而計算需要支付多少服務費用。

 

架構升級與業(yè)務發(fā)展

我們必須在保證業(yè)務不受影響的前提下，引入更加合理的技術架構，不斷發(fā)展和優(yōu)化技術架構，同時開發(fā)提供一系列穩(wěn)定的業(yè)務應用程序運行于技術架構之上;

需要支持快速的技術發(fā)展，同時保護業(yè)務應用程序不受技術升級的影響;

不及時處理技術債務的IT領導者有造成軟件和組織面臨挑戰(zhàn)的風險。技術債務會打亂業(yè)務，甚至會產(chǎn)生更多的債務，同時導致不良實踐的野蠻生長和頂級人才的流失;沒有先進的技術武器，再好的業(yè)務也會被人迎頭趕上。

7、云原生架構

上一節(jié)我們講到了架構的發(fā)展史，我們可以看出，目前正是從微服務時代過度到云原生時代的過程。基礎的云平臺提供：

• laas將會為我們提供計算、存儲、網(wǎng)絡等資源能力;
• PaaS將會為我們提供常用的技術基礎平臺，我們直接使用其API即可;

我們基于云平臺提供的運算能力，搭建自己的SaaS系統(tǒng)，最終通過DevOps部署到云上。關鍵層次劃分如下：

 

IaaS：Infrastructure-as-a-Service，基礎設施即服務，提供給消費者的服務是對所有計算基礎設施的利用，包括處理CPU、內存、存儲、網(wǎng)絡和其它基本的計算資源，用戶能夠部署和運行任意軟件，包括操作系統(tǒng)和應用程序;

PaaS：Platform-as-a-Service，平臺即服務，提供常用的技術組件方便系統(tǒng)的開發(fā)和維護。把客戶采用提供的開發(fā)語言和工具(例如Java，python, .Net等)開發(fā)的或收購的應用程序部署到供應商的云計算基礎設施上去;

SaaS：Software-as-a-Service，軟件即服務，提供開發(fā)好的應用或服務，按功能或性能要求付費。SaaS 是軟件的開發(fā)、管理、部署都交給第三方，不需要關心技術問題，可以拿來即用。普通用戶接觸到的互聯(lián)網(wǎng)服務，幾乎都是 SaaS。

想進一步了解單體應用如何拆分為微服務，然后上云，使用k8s進行部署，從而實現(xiàn)從單體應用走向云原生架構之路?方案架構師Andy Wu在Google云平臺討論了單體系統(tǒng)的問題，以及微服務的好處，服務上云計算的好處，并且通過一個真實的場景演示了遷移一個單體系統(tǒng)到這種新體系結構的過程。公眾號回復：g01 獲取一手完整資料。(英文版)

微服務中的分布式技術

在設計微服務系統(tǒng)，或者研究其底層原理的時候，會涉及到分布式基礎知識的方方面面：分布式事務處理、分布式鎖、分布式ID、分布式緩存、分布式搜索技術、分布式協(xié)調組件、消息隊列、高性能通信框架Netty。這個我們在分布式專題專門來探討下。

這篇文章的內容就差不多介紹到這里了，能夠閱讀到這里的朋友真的是很有耐心，為你點個贊。

本文為arthinking基于相關技術資料和官方文檔撰寫而成，確保內容的準確性，如果你發(fā)現(xiàn)了有何錯漏之處，煩請高抬貴手幫忙指正，萬分感激。

大家可以關注我的博客：itzhai.com 獲取更多文章，我將持續(xù)更新后端相關技術，涉及JVM、Java基礎、架構設計、網(wǎng)絡編程、數(shù)據(jù)結構、數(shù)據(jù)庫、算法、并發(fā)編程、分布式系統(tǒng)等相關內容。

如果您覺得讀完本文有所收獲的話，可以關注我的賬號，或者點個贊吧，碼字不易，您的支持就是我寫作的最大動力，再次感謝!

References

[1]: Dubbo Spring Cloud

https://github.com/alibaba/spring-cloud-alibaba/wiki/Dubbo-Spring-Cloud

[2]: Dubbo

http://dubbo.apache.org/zh-cn/docs/user/preface/architecture.html

[3]: Software Architecture AntiPatterns

https://sourcemaking.com/antipatterns/software-architecture-antipatterns

[4]: Escaping monolithic hell

https://livebook.manning.com/book/microservices-patterns/chapter-1/1

[5]: From building microliths to designing reactive microsystems

https://www.oreilly.com/radar/the-evolution-of-scalable-microservices/

[6]: An open-source benchmark suite for microservices and their hardware-software implications for cloud & edge systems

https://blog.acolyer.org/2019/05/13/an-open-source-benchmark-suite-for-microservices-and-their-hardware-software-implications-for-cloud-edge-systems/

[7]: 回歸單體 —— Istio的自我救贖?

https://www.servicemesher.com/blog/istio-self-salvation/

[8]: 用這 12 要素來構建你的應用程序

https://juejin.im/post/5dfdd9aef265da33b50740ee

構建微服務技術中臺，SpringCloud和Kubernetes該如何選型?

https://blog.csdn.net/yang75108/article/details/99706510

Adoption of Cloud-Native Architecture, Part 1: Architecture Evolution and Maturity 架構的演變和成熟度

https://www.infoq.com/articles/cloud-native-architecture-adoption-part1/

微服務架構初探

https://www.sohu.com/a/225603928_617676

Spring Cloud for Microservices Compared to Kubernetes

https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes/

微服務與SOA的差異

https://www.leanix.net/en/blog/microservices-vs-soa

Microservices vs SOA: What's the Difference?

https://dzone.com/articles/microservices-vs-soa-whats-the-difference

What is service-oriented architecture?

https://www.javaworld.com/article/2071889/what-is-service-oriented-architecture.html

Microservices vs SOA: What’s the Difference?

https://www.tiempodev.com/blog/microservices-vs-soa/

《分布式服務架構:原理、設計與實戰(zhàn)》

《Cloud-native-approach-with-microservices》

SpringCloud與Dubbo的比較

https://blog.csdn.net/xuri24/article/details/89283802

Dubbo 與 Spring Cloud 完美結合

https://www.cnblogs.com/babycomeon/p/11546737.html

Microservices Patterns

 

https://livebook.manning.com/book/microservices-patterns/about-this-book/

本文轉載自微信公眾號「Java架構雜談」，可以通過以下二維碼關注。轉載本文請聯(lián)系Java架構雜談公眾號。