軟件架構的演進
講正事兒之前，先講個故事——話說，從前有個叫周星星的少年，從擺街邊攤起家，通過自己的奮斗，最終成為飲食界的大亨。他的發(fā)家過程經歷了四個階段：
-
街邊攤階段：這時剛剛創(chuàng)業(yè)，一窮二白，要錢沒錢、要人沒人，自己什么都得做，賣材料、做飯菜、擺桌子、收錢，全都他一個人搞定。剛開始，客人不多，一個人游刃有余。后來，來光顧的客人也越來越多，一個人就忙不過來了，有時客人看要等很久就走了……于是，賺了些錢的他，盤算著開個小店……
街邊攤階段 -
快餐店階段：他招了幾個員工，簡單分為了三組：一組服務員，負責接送客人，人多的時候引導客人排隊；一組廚師，他自己做主廚，指導其他廚師做菜；一組采購，負責買菜等。就這樣，快餐店開起來了。三組人員各司其職……他家秘制的“撒尿牛丸”遠近聞名，客人絡繹不絕……但慢慢地，有客人反映，他家的菜品太少，沒辦法滿足客人的需求了……
快餐店階段 -
大酒店階段：為了滿足客人越來越高的要求，他把快餐店升級為大酒店。他成立了四大廚師部門，分別為客人提供川菜、東北菜、粵菜、湘菜四大不同菜系，通過統(tǒng)一的后勤、財務把這四大菜系管理起來……剛開始，一切都很好，賺的缽滿盆滿。但隨著生意越來越旺，客人越來越多，又開始出問題了：餐廳地方不夠！排隊的人越來越多。周星星打算開分店，但問題來了：這個分店，吃川菜的多，其他菜沒什么人吃；那個分店，吃粵菜的多，別的菜系廚師閑著……后來，又發(fā)生了一件事：吃東北菜的兩桌客人，一句“你愁啥”，一句“瞅你咋地”，就打起來了，攔都攔不住。這一鬧，把吃粵菜、川菜、湘菜的客人都給嚇跑了……精明的周星星一眼看出了問題，這是因為四個菜系共享了一個資源（餐廳），導致了一個服務出問題，別的服務都遭殃。他意識到，要繼續(xù)發(fā)展，企業(yè)的組織方式還得調整。
大酒店階段 -
飲食集團階段：周星星成立了周氏飲食集團，掌控各個子公司，每個子公司都有獨立的前臺、后勤，互不干擾，自負盈虧。還有一個額外的好處，比如這段時間日料流行，那就多開幾個日料店；又過一陣子，西餐流行，那就把日料店關一些，多開些西餐店。整個集團很靈活，總是能快速的抓住商機。至此，周星星成為飲食界的老大。
飲食集團階段
其實，軟件架構的演進過程和周氏企業(yè)演進過程是一模一樣的！軟件架構的演進也分為四個階段：單體架構（街邊攤）、分層架構（快餐店）、SOA架構（大酒店）和微服務架構（飲食集團）
單體架構：實際上沒什么架構的概念，所有的業(yè)務邏輯都在一個項目里打包成一個二進制的編譯后文件，通過這個文件進行部署，并提供業(yè)務能力。它就像上面的“街邊攤”，很小很靈活。但是處理能力有限；沒有分工，難以擴展。
分層架構：又叫“三明治”架構。分層架構中的每一層都著特定的職能。層之間是隔離的，即一個請求，必須一層一層的傳遞，而不能跨層傳遞。分層架構的流行，催生了大量的可復用的中間件。它就像上面的“快餐店”，有了明確分工的幾個組，團隊的能力大于個人，處理能力有了一定的提升。但是面對更復雜服務要求的時候，無論是擴展能力，還是服務能力，都有點力不從心。
SOA架構：即面向服務的架構（Service Oriented Architecture），它的關注點是服務。一個服務定義了一個相對獨立、自包含、可重用的業(yè)務功能。服務間一般通過企業(yè)服務總線（ESB）的方式組裝起來。它就像上面的“大酒店”，可以把各個較獨立的服務組裝起來，對外提供更復雜的服務，滿足客戶更多樣化的需求。SOA架構要提高擴展性，就需要采用“分布式”的方式了。那么，各種服務如何行“分布式化”？這就催生了下面要說的微服務架構。也可以認為，微服務架構就是SOA架構分布式化的一種實現。
微服務架構：以一組小而自治的服務來構建整個系統(tǒng)，系統(tǒng)的一大特點是去中心化，從而實現更靈活的擴展能力。它就像上面的“飲食集團”，每個服務都獨立而自治，整個系統(tǒng)（集團）具有很強的彈性，擴展自如，風險可控。當然，這樣的彈性是要付出一定代價的，后面我們再詳細分析。
回顧軟件架構的演進其實是與企業(yè)組織演進一樣的：都是為了滿足客戶越來越多、越來越復雜的需求，不斷調整軟件（企業(yè)）內部結構的過程。最后，都使得軟件（企業(yè)）的處理能力、擴展能力、抗風險能力等等更強。
微服務架構的產生
通過前面軟件架構演進史的介紹，可以對微服務的產生有個總體的認識。下面講講微服務具體是如何從SOA架構中衍生出來的。
可以說，微服務是在領域驅動設計（DDD）、持續(xù)交付（DevOps）、對Web的理解（REST）、六邊形架構、虛擬化平臺等一系列技術的基礎上，發(fā)展建立起來的。微服務架構應用這些技術解決了原來SOA中面臨的一系列問題?？梢哉f，這五大技術是微服務架構的基石，沒有它們，就不可能建立起微服務架構。
原SOA面臨的一些問題，及微服務對此的解決之道：
- 如何劃分服務：SOA雖然提出了以服務為核心的觀念，但是對于如何劃分服務，并沒有很好的指導方法?！邦I域驅動設計”理論為如何進行服務劃分提供了方法論。雖然對于微服務架構，如何劃分服務仍是一大難題，但比之前有了一定改善。
- 服務如何集成：持續(xù)集成及DevOps技術的發(fā)展，為自動化的服務集成，提供了一系列工具和解決方案。多個協(xié)同工作的服務需要集成測試、聯(lián)合部署，沒有自動化的持續(xù)集成基本無法實施。持續(xù)集成是微服務架構中的一個不可或缺的部分。
- 服務如何通信：隨著HTTP技術的發(fā)展，產生了RESTful的架構風格，它為服務之間通信和集成提供了很好的解決方案。其中最重要的一點是資源的概念，將服務看成是對外提供的一系列資源，資源在服務內的形態(tài)與客戶端能看到的表現形態(tài)是分離的。一般使用HTTP作為REST的底層通信協(xié)議。HTTP提供了get、post、put、delete等動詞，可以很好的表達對資源的使用；同時，HTTP周邊有一整套完善的生態(tài)系統(tǒng)，可以使得服務的通信、負載均衡、緩存、監(jiān)控等更加容易。
- 服務內部如何組織：六邊形架構通過對領域模型、應用、適配器的劃分，使得業(yè)務領域的邊界更加清晰，服務具有更好的可擴展性，更容易測試。微服務中的單個服務，一般使用六邊形的架構風格。
- 服務如何擴展：虛擬化技術的發(fā)展，尤其是Docker技術、云技術的發(fā)展，使得服務的分布式安裝、部署、彈性擴展成為一件相對容易的事。彈性擴展是微服務架構的一個重要優(yōu)點，脫離了虛擬化技術，這個優(yōu)點將很難實現。
微服務架構的特點
上面說了那么多微服務，到底什么才是微服務呢？這里姑且給出一個定義：微服務就是一些協(xié)同工作的小而自治的服務。所謂“小”，就是專注做好一件事；所謂“自治”，就是服務是獨立的實體，服務之間彼此獨立，修改部署一個服務不會影響其他服務。
按Martin Fowler大神的想法，微服務應該具備以下特點：
- 通過服務實現組件化：使用微服務作為組裝應用的組件，有三大好處：一是可以獨立部署、替換和升級；二是由于強迫使用網絡通信，會使得接口更加明確；三是可以實現不同技術棧的組合。
- 圍繞業(yè)務能力組織服務：按照業(yè)務劃分服務，更符合康威定律。一個服務可以由一個全棧團隊負責。相比分層架構，一個變更需要更少的溝通，也就更高效。
- 產品而非項目模式：微服務架構倡導一個團隊負責一個“微服務”完整的生命周期，把每個微服務當成一個產品來看待。
- 智能端點與啞管道：傳統(tǒng)SOA架構，強調ESB（企業(yè)服務總線）等中間件，試圖把這些中間件做得更智能；而微服務架構與此相反，更強調把這些智能放到端點（也就是微服務）中，而微服務之間的通信應盡量簡單。微服務就像Unix中的一個獨立的命令，他們間的通信就像Unix中的管道那么簡單。這也是微服務與傳統(tǒng)SOA的一個重要差別。
- “去中心化”治理：整體式應用往往傾向于采用單一技術棧，微服務架構則鼓勵使用最合適技術棧完成各自的任務。
- “去中心化”數據管理：微服務架構倡導讓每個微服務管理其自有數據，并允許不同微服務采用不同的數據持久化技術。
- 基礎設施自動化：通過持續(xù)集成和持續(xù)交付等方法自動化的構建、部署微服務。
- 為容錯設計：因為微服務可能隨時出現故障，微服務架構中實時監(jiān)控和日志機制非常重要，可以幫助快速發(fā)現故障。出現故障時微服務應該盡可能自動恢復。
- 演進式設計：微服務應用更注重快速更新，因此系統(tǒng)的設計會隨時間不斷變化及演進。
微服務架構的優(yōu)勢
“天下熙熙皆為利來，天下攘攘皆為利往”——這么多人追隨微服務而來，必有其“利”！相比之前的架構，微服務主要有下面幾個優(yōu)點：
- 技術異構性：微服務可以輕松采用不同的技術棧。
- 彈性：一個服務不可用不會導致整個系統(tǒng)不可用。
- 擴展：可以只針對那些需要擴展的微服務進行擴展。
- 簡化部署：不用重新部署整個應用，只需要部署個別服務，并可以快速回滾。
- 與組織結構相匹配：符合康威定律。
- 可組合性：對已有功能組合實現新的應用。
- 可替代性：重新實現某個服務相對容易些。
微服務架構的挑戰(zhàn)
俗話說：“天下沒有免費的午餐”，要獲得微服務帶來益處，是要付出一定代價的！下面看看微服務對比原來架構帶來了哪些挑戰(zhàn)：
1. 版本
各個微服務應該用統(tǒng)一版本號呢，還是各自獨立版本？”——一旦為圖方便，使用統(tǒng)一一個版本，就會使得微服務帶來的“自治、獨立發(fā)布部署”的優(yōu)點不復存在。而每個服務維護不同的版本，又為版本管理的復雜度帶來極大的挑戰(zhàn)。并且不同版本之間的兼容性測試也會十分復雜。
2. 代碼
重復的代碼怎么辦？——這還用問嗎？根據DRY原則，當然要抽取出來——然而，在微服務時，則不是這樣的。因為不同服務間一旦抽取了公共的業(yè)務邏輯，就意味著這兩個服務耦合在一起了。公共模塊的變更會影響這兩個服務。所以，一般建議微服務內遵守DRY原則，而跨服務可以適當違反DRY原則……這同時又帶來了另外一個問題，就是重構代碼會變得十分困難，出現共性的問題，可能需要多個團隊同時修改。在老板眼里，這就是資源浪費啊。
3. 界面
服務拆分了，那用戶界面怎么辦？——如果不分，那界面就是所有服務耦合的地方，很容易就退回到分層合作的模式；如果界面也分開，要怎么組合在一起，給用戶最終呈現一個統(tǒng)一的整體呢？雖然可以通過“UI片段組合”或者“前端專用后端”的方法予以解決，但其引入的復雜性也是一項不小的挑戰(zhàn)。
4. 數據
各服務是共享數據還是獨占數據？——如果共享數據，這些數據就是微服務之間耦合的點。一個微服務修改了數據或者數據結構，就可能對另外的服務產生影響。而如果數據分離到每個服務中，又帶來了一些新的挑戰(zhàn)，比如：如何保證事務的一致性、如何處理報表系統(tǒng)等等。這些都是設計上要面臨的挑戰(zhàn)。
5. 分布式
微服務架構是典型的分布式架構。天生具有分布式架構所面臨的挑戰(zhàn)?？梢粤私庖幌拢?a target="_blank" rel="nofollow">分布式系統(tǒng)的八大謬誤，CAP定理。這些復雜性，都是微服務架構需要克服的。
6. 監(jiān)控
監(jiān)控對于微服務架構十分重要。一個業(yè)務流程可能涉及多個微服務協(xié)同工作，日志散落在各處。如果沒有有效的監(jiān)控手段，出了問題將很難查。
7. 安全
服務之間的調用，能信任嗎？——如果全信任，意味著攻擊者只要進入內網中，就可以采用中間人攻擊任何服務。如果不信任，那服務之間的認證、鑒權、證書發(fā)布、證書管理等一系列復雜的安全問題，都是需要認真考慮的。
可見，微服務架構面臨的挑戰(zhàn)難度還是比較高的。雖然，現有的一些微服務框架可以幫助解決一部分問題，但要將微服務落地，這些挑戰(zhàn)仍然是需要認真面對的。
該不該用微服務架構？
關于這個問題，《微服務設計》的作者這樣建議道：
越不了解一個領域，為服務找到合適的限界上下文就越難。請考慮首先構建單塊系統(tǒng)，當穩(wěn)定以后再進行拆分。一塊塊地拆分你的系統(tǒng)，持續(xù)地改進和演進系統(tǒng)，擁抱變化！
我在此基礎上，再增加“四看”：
- 看系統(tǒng)規(guī)模
- 看組織結構
- 看基礎設施
- 看人員能力
1. 看系統(tǒng)規(guī)模：
從前面架構演進的歷史，可以知道微服務是為解決規(guī)模比較大的系統(tǒng)的問題而誕生的。如果現在的業(yè)務量以及未來一、兩年內的業(yè)務量都不會很大，一臺服務器就可以搞定，這樣小規(guī)模的系統(tǒng)就沒必要硬上微服務。因為這樣微服務帶來的挑戰(zhàn)比它帶來的好處大得多。
有些反對這個觀點的人說：“即使系統(tǒng)規(guī)模不大，使用微服務也可以使系統(tǒng)更解耦，后面擴展更容易”?！@是本末倒置了。并不是微服務架構使得系統(tǒng)更解耦，而恰恰相反，是解耦做好了，才能做好微服務架構！優(yōu)秀微服務架構實踐的前提是合理劃分服務，使得服務高內聚、低耦合，而不是反過來。微服務架構中劃分服務的方法論是DDD（按照限界上下文來劃分服務），這個方法論并不要求一定是微服務架構，各種架構都可以實施。正如前面所說“越不了解一個領域，為服務找到合適的限界上下文就越難”。微服務架構中，一旦服務邊界劃錯了，帶來的后果是災難性的；而不是分布式的架構中，這種錯誤的修正要容易得多。
2. 看組織結構：
微服務架構倡導的是每個服務由一個具備全棧能力的團隊負責。如果當前組織是按技能劃分的，比如前端團隊、后端團隊、數據庫團隊等，那就不是很合適。要么放棄微服務，要么調整組織結構。
3. 看基礎設施：
虛擬化/云化、持續(xù)集成等自動化基礎設施，是微服務實施和運維的有力保障。如果組織目前還不具備這些基礎設施，那么微服務的落地將面臨很多困難。
4. 看人員能力：
不管一開始看起來什么樣，它永遠是人的問題。
微服務架構賦權給開發(fā)人員以增進自治也是充滿挑戰(zhàn)的。過去人們習慣把工作扔給別人，習慣指責別人，現在要讓他們對自己的工作完全負責可能會讓其感覺不舒服。微服務架構要求研發(fā)團隊具備全棧技術能力，對單個研發(fā)人員的綜合素質要求也比以往更高。如果人員沒有從心理上和技能上準備好，強行推行微服務，很可能為失敗埋下種子。
最后，
按照InfoQ發(fā)布的2019架構和設計領域趨勢報告，微服務架構很可能進入晚期大眾階段，這也意味著，按照Gartner炒作周期，微服務架構已經走過了盲目追捧和幻滅谷底階段，開始逐漸走向成熟，走向切實可落地階段。
微服務是一個很容易被濫用或誤用的術語。本文從架構演進史入手，介紹了微服務架構的來龍去脈、它的優(yōu)點以及它帶來的挑戰(zhàn)。希望可以幫助大家更好的理解微服務架構。根據自己項目的實際情況，權衡利弊，決定是否向微服務架構演進。
