前言
隨著這幾年微服務(wù)的火爆，在平時(shí)的工作或者技術(shù)交流中，我們總能聽到哪家公司把自己的項(xiàng)目用微服務(wù)重構(gòu)啦，某位技術(shù)大佬在 XX 峰會(huì)上分享微服務(wù)相關(guān)技術(shù)經(jīng)驗(yàn)獲得大家的一致好評啦，好像微服務(wù)已經(jīng)在我們的工作中無處不在了？
關(guān)于這個(gè)問題，我想說：是的，微服務(wù)的時(shí)代已經(jīng)深入扎根中大公司的開發(fā)核心，筆者之前所有在老牌互聯(lián)網(wǎng)公司早在 2014 年就致力啟動(dòng)全面轉(zhuǎn)向微服務(wù)，目前仍然在整合 Service Mesh 與容器部署架構(gòu)。
但是，雖然微服務(wù)已經(jīng)這么火爆了，但是我發(fā)現(xiàn)在不同業(yè)務(wù)不同場景中探討微服務(wù)，很多時(shí)候大家聊得并不是同一個(gè)東西。事實(shí)上，到底什么是微服務(wù)，到目前為止業(yè)界還沒有一個(gè)最能蓋棺定論的定義。從這節(jié)課開始，我們就來討論下 “什么是微服務(wù)？”。
1. 什么是微服務(wù)
在業(yè)界中，有兩個(gè)人對微服務(wù)架構(gòu)的定義是產(chǎn)生了非常深遠(yuǎn)的影響，一個(gè)是 Martin Fowler，一個(gè)是 Netflix 架構(gòu)總監(jiān) Adrian Cockcroft，Netflix 公司對整個(gè)微服務(wù)架構(gòu)的推進(jìn)起到?jīng)Q定性的作用，相信已經(jīng)對微服務(wù)有過一定接觸的同學(xué)對 netflix 不會(huì)很陌生，前期的 Zuul，Hystrix，Eureka，Ribbon 等著名開源組件就是由 Netflix 所進(jìn)行開源。
Martin Fowler 在《Microservices》https://www.martinfowler.com/articles/microservices.html 中有一段對微服務(wù)進(jìn)行了一個(gè)核心點(diǎn)的定義
In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
這一小段是《Microservices》最重要的定義片段，微服務(wù)是一種架構(gòu)的風(fēng)格，在這個(gè)風(fēng)格下勾勒出幾個(gè)核心點(diǎn)：
- a suite of small services：一組小的服務(wù)；
- running in its own process：獨(dú)立的進(jìn)程；
- communicating with lightweight：輕量級(jí)的通訊；
- built around business capabilities：基于業(yè)務(wù)能力構(gòu)建；
- independently deployable：獨(dú)立部署；
- a bare minimum of centralized management：最小的中心化管理。
1.1 一組小的服務(wù)
一組 “小” 的服務(wù)，這個(gè)小其實(shí)是相對而言的，原來的單體服務(wù)都是把所有的業(yè)務(wù)大而全的打包在一個(gè)單體結(jié)構(gòu)中，而微服務(wù)將這些單體結(jié)構(gòu)進(jìn)行拆分，形成一個(gè)一個(gè)獨(dú)立的服務(wù)，這個(gè)小是相對原來大而全的結(jié)構(gòu)而言。
很多同學(xué)會(huì)糾結(jié) “小” 這個(gè)點(diǎn)，那么要多小的程度才為之 “小”，因?yàn)檫@個(gè)小并沒有特別和明確的規(guī)定，所有這也引申出來現(xiàn)在很多 DDD 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)來指引微服務(wù)的拆分，基本上一個(gè)微服務(wù)能讓一個(gè)開發(fā)人員能獨(dú)立的理解，就可以稱為一個(gè)微服務(wù)，具體有多少行代碼不是關(guān)鍵。
1.2 獨(dú)立的進(jìn)程
微服務(wù)是運(yùn)行在獨(dú)立的進(jìn)程當(dāng)中，例如 Java 程序部署在 Tomcat 的容器中，也可以將 Tomcat 部署在 Docker 容器中，因?yàn)槿萜鞅旧硪彩且环N進(jìn)程，所以微服務(wù)可以以進(jìn)程的方式去擴(kuò)展。
使用容器進(jìn)行部署，使得定義，部署與運(yùn)行一個(gè)微服務(wù)變的更加簡單，由于微服務(wù)粒度比傳統(tǒng)的 SOA 服務(wù)更小，它對 Web 應(yīng)用服務(wù)器的要求也變成更加的輕量級(jí)。
1.3 輕量級(jí)的通訊
微服務(wù)主張使用輕量級(jí)去構(gòu)建通訊機(jī)制，我認(rèn)為是使用基于 HTTP 協(xié)議的 API 資源，一般是 RESTful API。不過現(xiàn)在正式投入生產(chǎn)的應(yīng)用中，微服務(wù)之間的通訊絕不止于 RESTful，雖然 HTTP 協(xié)議相對來說較為簡單，但它在傳輸?shù)男阅芎涂煽啃砸泊嬖诒容^大的局限，特別是 JSON 在序列化也較弱。
所以在微服務(wù)內(nèi)部通訊會(huì)使用更多的 RPC 框架，例如 Netty，gRPC，阿里的 dubbo 協(xié)議等等，甚至還可以使用消息中間件來完成通訊傳輸。
究竟我們的服務(wù)應(yīng)該選擇 RPC 還是 RESTful，在后面的章節(jié)會(huì)進(jìn)行討論。
1.4 基于業(yè)務(wù)能力構(gòu)建
文中強(qiáng)調(diào)了服務(wù)的規(guī)劃和劃分，是基于業(yè)務(wù)進(jìn)行構(gòu)建，這一點(diǎn)非常的重要，是業(yè)務(wù)而非技術(shù)驅(qū)動(dòng)微服務(wù)的設(shè)計(jì)，這一個(gè)觀點(diǎn)從而也推動(dòng)了領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）的發(fā)展，越來越多的人嘗試將領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)引入微服務(wù)架構(gòu)的設(shè)計(jì)中。
例如：在電商的系統(tǒng)中，我們劃分服務(wù)更多考慮的是業(yè)務(wù)，例如：用戶服務(wù)，商品服務(wù)，訂單服務(wù)等等，這個(gè)在后面劃分服務(wù)的章節(jié)將會(huì)再進(jìn)行討論。
1.5 獨(dú)立部署
在以往的大型獨(dú)體項(xiàng)目中，部署和發(fā)布永遠(yuǎn)是高懸頭頂?shù)倪_(dá)摩克利斯之劍，某一個(gè)模塊的錯(cuò)誤都可能讓整個(gè)系統(tǒng)崩塌。
但是微服務(wù)的一個(gè)關(guān)鍵原則是：每一個(gè)服務(wù)都是系統(tǒng)的組件，均可以獨(dú)立的進(jìn)行部署，團(tuán)隊(duì)之間是不需要特別的進(jìn)行協(xié)調(diào)，當(dāng)我們開發(fā)和部署一個(gè)服務(wù)時(shí)，我們只需要確保測試和部署好一個(gè)服務(wù)，如果真的把它搞砸了，也不會(huì)把整個(gè)系統(tǒng)都搞砸。
當(dāng)然，一個(gè)服務(wù)掛掉了不會(huì)把整個(gè)系統(tǒng)都搞砸，還需要建立在一個(gè)好的微服務(wù)治理上，這個(gè)問題我們在后面的章節(jié)中也會(huì)討論。
1.6 最小的中心化管理
最小的中心化管理，其實(shí)也可以稱為 “無集中式管理”， 原來的單體服務(wù)需要整個(gè)技術(shù)團(tuán)隊(duì)都是獨(dú)立的架構(gòu)團(tuán)隊(duì)去進(jìn)行管理，統(tǒng)一的架構(gòu)，統(tǒng)一的技術(shù)棧，統(tǒng)計(jì)的存儲(chǔ)。
而在微服務(wù)中得益于服務(wù)的拆分，人員的拆分，所以在實(shí)施微服務(wù)將不再受限于系統(tǒng)的技術(shù)棧，無論是開發(fā)的語言，數(shù)據(jù)庫，緩存都是可以進(jìn)行自由的選擇。從理論上來說，微服務(wù)是一種通過網(wǎng)絡(luò)協(xié)議的跨平臺(tái)調(diào)用，只要規(guī)定好服務(wù)的接口和服務(wù)的網(wǎng)絡(luò)協(xié)議，服務(wù)本身的技術(shù)都是可以自由選擇的。
對每個(gè)系統(tǒng)本身來說，是最小的中心化管理，但是，如果從整個(gè)微服務(wù)的系統(tǒng)架構(gòu)來說，我們需要考慮到整個(gè)微服務(wù)的注冊，發(fā)現(xiàn)，降級(jí)，監(jiān)控，編排等等，這也衍生了我們對微服務(wù)更多的 “管理中心”，例如我們會(huì)使用 SpringCloud 或 Dubbo 框架進(jìn)行管理。
1.7 究竟什么是微服務(wù)
是否我們達(dá)到了 Martin Fowler 講的以上 6 點(diǎn)就是 “微服務(wù)”，或者說是否一定要達(dá)到以上的 6 點(diǎn)才能稱之為 “微服務(wù)”。其實(shí)也不一定 Adrian Cockcroft 之前也給過微服務(wù)一個(gè)定義
Loosely coupled service oriented architecture with bounded contexts.
只要是 “松散耦合的、面向服務(wù)的、基于有界上下文的” 也可以成為微服務(wù)。可見微服務(wù)并沒有一個(gè)并沒有百分百的定義，更多是一種風(fēng)格，我們需要的是理解這種風(fēng)格對我們技術(shù)業(yè)務(wù)的推動(dòng)。
2. 是否要實(shí)施微服務(wù)
上面我們整體的認(rèn)識(shí)了什么是微服務(wù)，那么問題就來了，既然微服務(wù)已經(jīng)這么火爆了，那于鏊不要在我們的業(yè)務(wù)中也實(shí)施微服務(wù)呢？
是否需要微服務(wù)這個(gè)問題的答案，要從實(shí)際業(yè)務(wù)中去得到：
2.1 單體應(yīng)用的瓶頸
在以往傳統(tǒng)的系統(tǒng)架構(gòu)中，我們在構(gòu)建一個(gè)單體結(jié)構(gòu)一般都是由：前端展示層，服務(wù)業(yè)務(wù)層，存儲(chǔ)數(shù)據(jù)層來組成。
業(yè)務(wù)發(fā)展初期，由于所有的業(yè)務(wù)邏輯都在一個(gè)應(yīng)用中。開發(fā)，測試，部署來說都比較的輕量和方便。但隨著業(yè)務(wù)的發(fā)展，系統(tǒng)為了對應(yīng)不同的業(yè)務(wù)就得往單體項(xiàng)目增加不同的業(yè)務(wù)模塊，慢慢的不斷追加的業(yè)務(wù)模塊會(huì)使得單體應(yīng)用變得越來越臃腫。
隨著時(shí)間的增長，所有的業(yè)務(wù)都在一個(gè)應(yīng)用里面，往往一個(gè)很小的功能修改都可能影響到其他的功能運(yùn)行。
并且，在單體應(yīng)用中，各個(gè)模塊的使用場景，并發(fā)量和系統(tǒng)所需要消耗的資源各不相同，資源處在于相互影響和相互競爭，這個(gè)就導(dǎo)致了我們很難去評估和預(yù)估所需要提供的資源。
上述說的問題，微服務(wù)的誕生就是為了解決單體系統(tǒng)變得臃腫難以維系的問題，將不同的功能點(diǎn)拆分不同服務(wù)，讓服務(wù)各自獨(dú)立運(yùn)行，同時(shí)，由于是獨(dú)立運(yùn)行，我們也可以更好的評估每個(gè)服務(wù)所需要的資源。
2.2 應(yīng)用微服務(wù)的時(shí)機(jī)
剛剛上述說了微服務(wù)可以解決單體應(yīng)用在臃腫的業(yè)務(wù)，部署難度大，資源和擴(kuò)展難以評估，阻礙團(tuán)隊(duì)的技術(shù)革新等問題，那是否我們就可以直接從單體應(yīng)用轉(zhuǎn)化為微服務(wù)？
答案明顯并不是這樣，下面是 Martin Fowler 給的 微服務(wù) / 單體 在隨著業(yè)務(wù)和時(shí)間進(jìn)度推移反映到生產(chǎn)力的關(guān)系圖：
根據(jù)上圖，我們知道生產(chǎn)力和業(yè)務(wù)的復(fù)雜度是有關(guān)系的，在復(fù)雜度小的時(shí)候采用單體應(yīng)用生產(chǎn)力會(huì)更高，但到了一定得規(guī)模，中間有一個(gè)臨界點(diǎn)，只有過了這個(gè)臨界點(diǎn)，單體服務(wù)的生產(chǎn)力直線下降，這個(gè)時(shí)候采用微服務(wù)才能正在的提升效率。
所以，要不要采用微服務(wù)架構(gòu)，何時(shí)采用微服務(wù)必須根據(jù)業(yè)務(wù)場景去做評估，實(shí)施微服務(wù)對架構(gòu)也提出來很多的挑戰(zhàn)，拆分服務(wù)也帶來了在單體應(yīng)用中所沒有的問題：
例如服務(wù)治理的問題，雖然說微服務(wù)實(shí)現(xiàn)了最小化集中管理，但那是建立在有一個(gè)統(tǒng)一良好的治理體系里面，如果忽略治理也可能因?yàn)槟硞€(gè)局部服務(wù)造成整體服務(wù)的崩塌。還有分布式所帶來一系列復(fù)雜性的問題，運(yùn)維會(huì)迎來新的挑戰(zhàn)，需要運(yùn)維的進(jìn)程數(shù)量會(huì)大大的增加，還有如何將這些服務(wù)進(jìn)行編排也是一個(gè)比較重要的問題。
這一系列的問題將在后面得章節(jié)中討論，要從一個(gè)單體應(yīng)用轉(zhuǎn)型為微服務(wù)應(yīng)用需要做什么呢，請看下一小節(jié)《單體服務(wù)轉(zhuǎn)為微服務(wù)體系需要注意什么問題？》。