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