編者語：

微服務，就是將單體（monolithic）代碼分解為易于維護的塊，而這正是運維（devops）哲學的關鍵。或者說是基于不斷擴展的業(yè)務而實現(xiàn)針對業(yè)務功能域的應用商業(yè)價值的快速交付或敏捷響應。

那么如何認識理解微服務，或說微服務到底哪些價值特征點值得作為下一個軟件架構的優(yōu)先選項呢？那本篇文章，就是希望通過簡明扼要闡述，促進你把微服務納入下一個優(yōu)選架構選項。

本文由牛旦課堂原創(chuàng)，版權歸創(chuàng)作者所有，轉載請注明來源或私信聯(lián)系。

1 導語

幾乎每個計算機系統(tǒng)都會使用共享資源來執(zhí)行多個任務，而計算機編程的問題之一，就是執(zhí)行這些任務的代碼位之間應該需要有多緊密才合適？一個越來越流行的答案就是微服務，——一個小而離散的功能塊，它通過與其他微服務交互而創(chuàng)建更大的應用系統(tǒng)。

盡管擁有這種離散組件的基本思想并不新鮮，但微服務的實現(xiàn)方式，使其成為兩個現(xiàn)代基于云的應用程序的天然基礎。微服務還與devops哲學相吻合，即后者鼓勵快速、持續(xù)地推出新功能。

2 微服務是個什么鬼？

微服務(microservices)中的微(“micro”)意味著這些都是小型應用程序。有時這是對的，但更好的思考或理解方式是，它們應該只大到能做好一件特定的事情或解決一個特定的問題,這就足夠了（或者這可看作為微服務上下文的“邊界”）。這個問題應該是概念性的，而不是技術性的。正如微軟所說，“微服務應該圍繞業(yè)務功能而設計，而不是像數(shù)據(jù)訪問或消息傳遞這樣的水平層次。”(Microservices should be designed around business capabilities, not horizontal layers such as data access or messaging.)它們通過相對穩(wěn)定的api與其他微服務和外部用戶通信，從而創(chuàng)建更大的應用程序。

因此，可以在不影響系統(tǒng)其余部分的情況下調整或徹底升級單個微服務的內部功能。這反過來又與devops團隊尋求的運營方式有關:如果大型應用程序的特定功能被分割成離散的、獨立的操作代碼片段，那么就更容易實現(xiàn)devops的CI/CD(continuous integration and continuous delivery,持續(xù)集成和持續(xù)交付)價值哲學。另外，定義良好的api使微服務易于實現(xiàn)自動化測試。

3 微服務架構和單體架構

我們經常會聽到人們用“微服務體系結構”或微服務架構來談論微服務。這個短語不僅包括微服務本身，還包括用于管理和服務發(fā)現(xiàn)的組件，以及處理微服務與外部世界之間通信的API網(wǎng)關。

單體應用程序是微服務的對立面。對于所有代碼都在一個巨大的二進制可執(zhí)行文件中的應用程序來說，它是一種倒退。正如TechTarget解釋的那樣，單體應用程序很難擴展，也很難改進。但是因為它是作為單一內聚應用程序構建的，所以它不需要像微服務架構那樣有許多的管理事務。從這點講，確實是有倒退之嫌。

4 邊界：如何定義微服務？

讓我們回顧一下之前的“戒律”，即微服務應該做一件特定的事情。說起來容易，但在實踐中，功能常常是相互交織的，繪制出分區(qū)比看上去要困難得多。領域分析和領域驅動設計(Domain analysis & domain-driven design)是微服務的指導理論方法，可以幫助我們將總體任務分解成微服務可以解決的單個問題。在這個過程中，需要創(chuàng)建業(yè)務領域的抽象模型，并在這個過程中發(fā)現(xiàn)邊界上下文，它將以特定方式把與相應領域交互的功能組合在一起而形成的微服務。

例如，您可能有一個邊界上下文用于運輸，而另一個用于賬目之用。當然，現(xiàn)實中的一個物理對象，既有價格也有需要去的地方，而邊界上下文就是代表應用程序要考慮這些對象以及與之交互的特定方式。每個微服務應該完全存在于單個邊界上下文中，盡管有些邊界上下文可能包含多個微服務——需要明白，微服務有單個核心服務和流程服務構成。

5 微服務與SOA架構及Web服務

在這一點上，如果你是一名IT專業(yè)人員，并且已經在這個行業(yè)工作了一段時間，那么可能會認為這些內容聽起來很熟悉。小型的單個程序協(xié)同工作的想法可能會讓您想起SOA(service-oriented architecture，面向服務的體系結構)和Web服務，這兩個流行詞來自二十一世紀令人興奮的Web 2.0時代。雖然從某種意義上說，世界上確實沒有什么新東西，但這些概念和微服務之間存在著重要的區(qū)別。Datamation網(wǎng)站上有篇何為微服務（https://www.datamation.com/cloud-computing/what-is-microservices.html）對這些差異有一個很好地細分，但這里有一個簡短的版本概述如下:

? 在SOA面向服務的體系結構中，各個組件相對緊密耦合，通常共享存儲等資產，并且它們通過稱為ESB（enterprise storage bus企業(yè)存儲總線）的專用軟件進行通信。微服務更加獨立，共享的資源更少，并且通過更輕量的協(xié)議進行通信。值得注意的是，微服務產生于SOA環(huán)境，有時被認為是SOA的一種，或者是概念的繼承者。

? Web服務是一組面向公眾的功能，其他應用程序可以通過Web訪問它;最流行的例子可能是谷歌地圖，餐館的網(wǎng)站可以嵌入它以為顧客提供方向定位。這種連接比您在microservices體系結構中看到的要松散得多。

6 微服務通訊

我們經常聽到的關于微服務架構的一個口號是，它們應該具有“智能端點和啞管道”（smart endpoints & dumb pipes.）的特性。換句話說，微服務的目標應該是使用基本的和完善的通訊方法，而不是復雜的和緊密集成方式。如上所述，這是微服務與SOA的另一個區(qū)別。

一般來說，微服務之間的通信應該是異步的(asynchronous)，因為代碼線程不會被阻塞而來等待響應。(盡管AMQP(Advanced Message Queuing Protocol，高級消息隊列協(xié)議)等異步協(xié)議在微服務架構中也很常見，但使用HTTP等同步通信協(xié)議仍然很好。)這種松散耦合使得微服務架構在面對網(wǎng)絡的單個組件或部分故障時更加靈活，這是一個關鍵的好處。

7 Microservices、JAVA、Spring Boot 與 Spring Cloud

微服務的一些最初的工作出現(xiàn)在Java社區(qū),馬丁·福勒(Martin Fowler)是早期的支持者。2012年在波蘭舉行的Java會議上有一個關于這個主題的最重要的早期報告，題目是“微服務—Java, Unix方式”（http://2012.33degree.org/talk/show/67）。它建議以此作為指導20世紀70年代第一批Unix應用程序開發(fā)的原則(編寫只做一件事的程序并把它做好。編寫要一起工作的程序)，并也適用Java開發(fā)。

這段歷史的結果是，有許多Java框架允許您構建微服務。其中最流行的是Spring Boot，它是專門為微服務設計的;Spring Cloud擴展了Spring Boot，顧名思義，它允許你將這些服務部署到云上。Spring的開發(fā)人員Pivotal Software提供了一個很好的教程，介紹如何使用這些框架來開始微服務的開發(fā)。

8 微服務和容器: Docker, Kubernetes及更多

在使微服務成為主流方面走得最遠的底層技術是容器。容器類似于VM實例，但它不包括整個自包含的操作系統(tǒng)，容器只是一個獨立的用戶空間，它利用主機操作系統(tǒng)的內核，且在內核中執(zhí)行的代碼保持自包含。容器比VM實例小得多，而且很容易快速部署(本地或云中)，并且可以向上或向下旋轉以匹配需求和可用資源。

容器對微服務的吸引力是顯而易見的:每個單獨的微服務可以在自己的容器中運行，這大大減少了管理服務的開銷。大多數(shù)容器實現(xiàn)都具有互補的編配工具，這些工具可以實現(xiàn)自動部署、管理、擴展、聯(lián)網(wǎng)和基于容器的應用程序可用性。小型、易于構建的微服務和易于部署的容器的結合使得運維devops哲學成為可能。容器概念有幾種實現(xiàn)，但目前最流行的是Docker，它通常與Kubernetes一起作為編排平臺。

Spring雖然很流行，但它是與Java平臺綁定的。另一方面，基于容器的系統(tǒng)是多語言的:OS支持的任何編程語言都可以在容器中運行，這為程序員提供了更大的靈活性。實際上，微服務的一大優(yōu)勢在于，每個服務都可以用最合適的或者開發(fā)人員最喜歡的語言來編寫。實際上，只要服務的api保持穩(wěn)定，就可以在不影響整個系統(tǒng)的情況下，用一種新的語言完全重新構建服務。DZone有一篇文章討論了用于微服務的Spring Cloud與Kubernetes的優(yōu)缺點。

9 微服務設計模式

無論使用哪種語言來開發(fā)微服務，都將面臨其他開發(fā)人員以前遇到過的問題。設計模式是對計算機科學中重復出現(xiàn)的問題的形式化、抽象化的解決方案，其中許多是專門為微服務設計的。Devopedia網(wǎng)站上有一個很棒的列表，包括:

? 服務注冊（Service Registry）:用于將客戶端連接到可用的微服務實例；
? 斷路器（Circuit Breaker）:防止已失敗或出故障的服務被反復調用；
? 回退（Fallback）:用于為失敗的服務提供替代方案；
? 跟蹤服務（Sidecar）:為主容器提供輔助服務，例如用于日志記錄、同步服務或監(jiān)視；
? 適配器（Adapter）:標準化或規(guī)范化主容器和外部世界之間的接口；
? 代理大使（Ambassador）:將主容器與外部世界連接，例如將本機連接代理到外部連接。

10 微服務和云: 華為、阿里、AWS 和 Azure

如上所述，使用容器的優(yōu)勢之一是可以輕松地將其部署到云中，云中有靈活的計算資源，因此可以最大限度地提高應用程序的效率。可以想象，主要的公共云供應商都希望你使用他們的平臺來運行基于微服務的應用程序。有關更多信息，請查看來自阿里云、華為、騰訊以及Amazon、Microsoft和谷歌的相關資源。