微服務并不是孤立存在的，它們存在于一個環境裡，微服務在這個環境裡進行互動。把這種環境看成微服務生态系統并分層，有助于了解微服務架構。
在一個設計良好的微服務生态系統裡，微服務與基礎設施之間是分離的。微服務與硬體、網絡、建構和部署管道、服務發現和負載均衡都是分離的。它們都是微服務生态系統基礎設施的組成部分。如何以一種穩定可靠的、可伸縮的、可容錯的方式來建構、維護和标準化基礎設施，是微服務運維的根本。
基礎設施必須能夠支撐微服務生态系統。基礎設施工程師和架構師的共同目标是為微服務的開發工作隐藏底層的運維細節，并建構一個穩定的、可伸縮的基礎設施平台，讓開發者可以輕松地在上面建構和運作微服務。在一個穩定的微服務生态系統裡開發一個微服務應該跟開發一個小型的标準應用一樣，都需要一個出類拔萃的基礎設施的支援。
微服務生态系統可以被分為4 層，雖然層與層之間的邊界不一定都很清晰，但這些層會涉及基礎設施的幾個元素。底下的3 層是基礎設施層：最下面的是硬體層，其次是通信層（一直滲透到第4 層），緊接着的是應用平台層。第4 層（頂層）就是微服務所在的層。
微服務生态系統的4層模型
微服務生态系統的底層是硬體層。這一層是伺服器實體機所在的層，它們是所有内部工具和微服務運作的基礎。這些伺服器被放置在資料中心的機架上，由供電系統供給電力，使用着昂貴的HVAC 冷卻系統。這裡有各種各樣的伺服器：有些專門用于運作資料庫，有些專門處理CPU 密集的任務。它們有些是某些公司私有的，有些是從所謂的“雲服務提供商”那裡租來的，比如Amazon Web Services Elastic Compute Cloud（AWS EC2）、Google Cloud Platform（GCP）或Microsoft Azure。
硬體的選擇取決于伺服器的所有者。如果你的公司有自己的資料中心，硬體的選擇就是自己的事情，完全可以根據實際需要來定制伺服器。如果你的伺服器是在雲端（這種情況比較普遍），你就沒有太多的選擇餘地。是自己購買伺服器還是選擇雲服務并不是一個簡單的選擇題，它需要考慮購買成本、可用性、可靠性和營運成本。
管理伺服器是硬體層的職責之一。每台伺服器都需要安裝标準的作業系統。使用哪種作業系統并沒有一個标準的答案，這完全取決于你要建構的應用程式、建構應用程式所使用的程式設計語言以及建構微服務所需要的軟體包和工具。主流的微服務生态系統一般會使用Linux 的變形版本，比如CentOS、Debian 或Ubuntu，不過一個使用了.NET 平台的公司顯然會有不同的選擇。硬體層之上還可以有一些層，比如資源隔離、資源抽象（由Docker 和Apache Mesos 提供的）和資料庫（專門的或共享的）。
作業系統的安裝和硬體資源的配置是伺服器的第一個層。每個主機必須被配置好，而且在安裝好作業系統之後，必須提供一個配置管理工具（比如Ansible、Chef 或Puppet）來安裝應用程式，并做好必要的配置。
對主機進行主機級别的監控（使用Nagios）是有必要的，而且需要記錄主機級别的日志。在主機出現異常（磁盤錯誤、網絡錯誤或CPU 過載）時就可以友善地對它們進行診斷，有助于問題的解決。
==硬體層的主要内容==
微服務生态系統的硬體層（第1 層）包含：
- 實體伺服器（公司自有或從雲服務提供商那裡租用）
- 資料庫（專有的或共享的）
- 作業系統
- 資源隔離和資源抽象
- 配置管理
- 主機級别的監控
- 主機級别的日志
微服務生态系統的第2 層是通信層。通信層滲透到生态系統的所有層（包括應用平台層和微服務層），因為微服務之間的互動會在多個層上進行，是以很難清晰地對通信層與其他層之間的邊界進行定義。雖然難以清晰地定義它們之間的邊界，但是這個層所涉及的元素是很明确的。第2 層一般包含網絡、DNS、RPC 和API 端點、服務發現、服務注冊以及負載均衡。
有關通信層網絡和DNS 元素的内容已經超出了本文的範疇，在這裡，我們主要讨論RPC、API 端點、服務發現、服務注冊和負載均衡。
微服務通過遠端過程調用（RPC）或消息傳送與其他微服務進行互動，這些調用通過網絡發送到其他微服務的API 端點上（如果使用的是消息傳遞，消息會被發送到消息代理，消息代理會對這些消息進行路由）。基本原理是這樣的：使用一個特定的協定，一個微服務把符合特定格式的資料通過網絡發送到另一個服務（或者是另一個微服務的API 端點）或消息代理上（消息代理確定資料會被路由到其他微服務的API 端點上）。
微服務有幾種通信方式，第一種是最常用的HTTP+REST/Thrift。如果使用的是這種方式，各個服務使用超文本傳輸協定（HTTP）進行網絡互動，它們向特定的REST 端點（使用各種HTTP 方法，比如GET、POST 等）或Thrift 端點發送請求或從這些端點接收響應。發送的資料一般是JSON（或protocol buffer）格式。
HTTP+REST 是最便利的微服務通信方式。它使用起來很簡單，而且穩定可靠。不過它的不足之處在于它是同步（阻塞）的。
第二種通信方式是消息傳遞。消息傳遞是異步（非阻塞）的，不過相對複雜。消息傳遞的工作原理是這樣的：一個微服務把資料（消息）通過網絡（HTTP 或其他）發送給一個消息代理，消息代理會把消息路由到其他微服務上。
消息傳遞也有幾種模式，最流行的兩種分别是釋出和訂閱以及請求和響應。如果使用的是釋出和訂閱模式，用戶端會訂閱一個主題，它将從主題上收到釋出者釋出的任何一個消息。請求和響應模式就更直接了，用戶端發送一個請求到一個服務（或消息代理）上，這個服務會對這個請求做出響應。有些消息中間件同時支援兩種模式，比如ApacheKafka。Celery 和Redis（或Celery 和RabbitMQ）可以為Python 微服務傳送消息（并處理任務）：Celery 處理任務或消息，Redis 或RabbitMQ 作為消息代理。
消息傳遞有幾個缺點需要注意。消息傳遞不會比HTTP+REST 具備更強的伸縮性，如果你的系統對伸縮性有要求的話一定要清楚這一點。消息傳遞對變更不友好，因為它是集中式的，這樣會導緻消息隊列和消息代理變成整個生态系統的故障點。它的異步特性在并發環境裡會導緻競賽條件，如果沒有處理好，還會出現無限循環。在使用消息傳遞時，如果能夠處理好上述這些問題，它會變得跟同步解決方案同樣穩定和高效。
在單體應用架構裡，所有的業務流量都被發送給負載均衡器，然後被分發到應用伺服器上。而在微服務架構裡，業務流量被路由到大量不同的應用程式上，然後再被分發給部署了特定微服務的伺服器。為了能夠高效地實作上述場景，微服務架構需要在通信層實作三項技術：服務發現、服務注冊和負載均衡。
一般來說，如果微服務A 需要向微服務B 發起請求，那麼微服務A 需要知道微服務B 的IP 位址和端口。微服務的通信層需要知道這些微服務的IP 位址和端口，才能正确地路由這些請求。這個問題可以通過服務發現（比如etcd、Consul、Hyperbahn 或ZooKeeper）來解決，服務發現可以確定請求會被路由到它們本該去的地方，而且隻會被路由到正常運作的執行個體上（這非常重要）。服務發現需要用到服務注冊，服務注冊中記錄了生态系統裡所有微服務的IP 位址和端口。
動态伸縮和端口配置設定
在微服務架構裡，在對微服務進行橫向擴充和重新部署時（比如使用了像Apache Mesos 這樣的硬體抽象層），端口和IP 位址會發生變化。在這種情況下，可以考慮為每個微服務配置設定一個靜态端口（包括前端和後端）。
除非你的所有微服務都部署在同一個執行個體上（一般不太可能），否則需要在通信層使用負載均衡。簡單地說，負載均衡可以做到：如果你有10 個微服務執行個體，負載均衡器（軟體或硬體）可以確定業務流量被（均衡地）分發到所有的執行個體上。在微服務生态系統裡，隻要涉及請求轉發，都需要用到負載均衡器，這意味着一個大型的微服務生态系統将包含多層負載均衡。常見的負載均衡器有Amazon Web Services Elastic Load Balancer、Netflix 的Eureka、HAProxy 和Nginx。
==通信層的主要内容==
微服務生态系統的通信層（第2 層）包含：
- 網絡
- DNS
- 遠端過程調用（RPC）
- 端點
- 消息傳遞
- 服務發現
- 服務注冊
- 負載均衡
應用平台層是微服務生态系統的第3 層，這一層包含了所有獨立于微服務的内部工具和服務。這一層所包含的集中式的工具和服務跨越了整個生态系統，因為有了這些工具和服務，微服務開發團隊就可以把精力集中在微服務的開發上。
一個好的應用平台需要為開發者提供一套内部的自助工具，包括标準化的開發流程、集中式的自動化建構和釋出系統、自動化測試、标準化和集中式的部署方案以及集中式的日志和微服務級别的監控。這些元素的細節此處不進行探讨，不過我們也會簡要地介紹其中的幾個元素，闡述一些基本的概念。
有很多東西可以被納入内部自助開發工具的範疇，它們是否可以被歸為這類工具不僅取決于開發者對工具的需求，還要考慮基礎設施和生态系統的整體抽象度和複雜性。決定使用哪一種工具，首先要對責任領域進行切分，然後對開發者所要完成的任務進行評估，以便設計、建構和維護他們的服務。
在一個已經使用了微服務架構的公司裡，給工程團隊指派職責要十分謹慎。最簡單的做法是為微服務生态系統的每一個層組建一個工程子團隊。這些工程子團隊将負責處理它們所在層的所有相關事務：運維團隊負責第1 層，基礎設施團隊負責第2 層，應用平台團隊負責第3 層，微服務團隊負責第4 層（這看起來很簡單，隻要你能明白就好了）。
在這種組織結構裡，工作在上層的工程師需要使用自助工具對下層的一些東西進行配置。例如，負責消息服務的團隊應該為其他開發者提供一個自助工具，當微服務團隊的開發者需要為他們的服務配置消息系統時，他們就可以使用這個工具，而無須過多地了解紛繁複雜的消息系統。
使用這些集中式的自助工具是有原因的。在一個多元化的微服務生态系統裡，一個團隊的普通工程師對其他團隊的系統和服務并不了解（或知之甚少），他們也不可能成為面面俱到的專家。每個開發人員隻對自己負責的部分比較了解，但從整個生态系統來看，這些開發人員組合在一起就無所不知了。為生态系統的每一部分建構易用的使用者界面，為開發人員提供相關的教育訓練，以便教會他們如何使用這些工具，而不是試圖讓每個開發人員了解這些工具和服務紛繁複雜的内部細節。把所有的事情放到一個黑匣子裡，然後提供詳細的說明文檔。
使用這些工具的第二個理由是，你不需要其他團隊的人來對你的服務和系統做任何關鍵性的改動，因為這些人可能會給你們帶來麻煩。對于底層（第1 層、第2 層和第3 層）的服務和系統來說，更是如此。讓他們在這些層上面做出改動，或者要求（更糟糕的是期待）他們成為某方面的專家有可能會釀成大禍。舉一個配置管理的例子：不具備相關專門知識的微服務團隊開發人員對系統配置做了一些變更，這有可能導緻大規模的服務癱瘓，因為他們所做的變更有可能不隻是影響到他們自己的服務。
開發人員在對已有微服務進行修改或建構新的微服務時，對開發流程進行流水線化、标準化和自動化可以大幅提升開發效率。對開發流程進行标準化将在第4 章進行探讨。有些東西需要被放在微服務生态系統的第3 層，讓穩定可靠的開發成為可能。
首先是集中式的版本控制系統，這個系統儲存了所有代碼，允許對代碼進行跟蹤、版本管理和搜尋。這個可以通過一些工具來實作，比如GitHub 或者自有的git 或svn 代碼倉庫，可以将這些倉庫和一些協作工具內建起來，比如Phabrictor，以簡化代碼的維護和審查工作。
其次是穩定高效的開發環境。衆所周知，在微服務生态系統裡實作一個這樣的開發環境是很困難的，因為微服務之間的依賴太過複雜。不過它們都是最基本的因素，我們無法避免。一些工程組織傾向于在本地完成開發工作（在開發人員的電腦上），不過這樣會導緻糟糕的部署，因為開發人員并不清楚他們修改的代碼是如何被部署到生産環境的。最穩定可靠的建構開發環境的方式是為生産環境建立一個鏡像（不是為了預生産，也不是為了收集回報，更不是為了生産），這個鏡像包含所有複雜的依賴關系鍊。
開發過程中的測試、建構、打包和釋出應該盡量被标準化和集中化。在開發結束之後，當有代碼變更被送出，需要運作相關的測試用例，然後自動建構和打包即将釋出的新版本。這個時候，持續內建工具就可以派上用場，一些現成的解決方案（比如Jenkins）不僅功能齊全而且使用友善。這些工具可以讓整個過程自動化，幾乎不留給人類任何犯錯的機會。
在經過了開發、測試、建構、打包和釋出這些步驟之後，部署管道是新代碼走向生産環境的另一個流程。在一個微服務生态系統裡，部署會在很短的時間内變得極其複雜，每天上百個部署都是很平常的事。開發團隊需要為開發建構工具，并對開發過程進行标準化。
所有的微服務都應該把與它們的請求和響應相關的重要資訊記錄到日志裡。因為微服務變更的速度太快，如果系統發生了錯誤，重建當時的系統狀态變得很困難，導緻代碼的缺陷難以重制。使用微服務級别的日志可以幫助開發人員更好地了解他們的服務在過去某個時刻或目前時刻的狀态。在微服務級别對微服務的關鍵度量名額進行監控也是出于同樣的目的：實時準确的監控可以幫助開發人員了解服務的狀态和健康狀況。
微服務生态系統的應用平台層（第3 層）包含：
- 内部自助開發工具
- 開發環境
- 測試、建構、打包和釋出工具
- 部署管道
- 微服務級别的日志
- 微服務級别的監控
微服務生态系統的頂層是微服務層（第4 層）。這一層是微服務以及微服務所有相關事物所在的層，它與底下的基礎設施層完全分離，比如硬體、部署、服務發現、負載均衡和通信。微服務層唯一沒有被分離的是使用自助工具所做的配置。
在軟體工程裡，應用的配置一般會被集中化，針對某個工具或某些工具（配置管理、資源隔離或部署工具）的配置可以和這些工具儲存在一起。例如，應用程式的自定義部署配置一般會和部署工具的代碼儲存在一起，而不是和應用程式的代碼儲存在一起。這種方式對單體應用架構或小型的微服務生态系統來說是沒有問題的，但在包含了大量微服務和内部工具（每個工具都有自定義的配置）的大型微服務生态系統裡，這種方式就會造成混亂：處在上層的微服務團隊需要修改處在下層的工具代碼，他們會經常忘記哪些地方包含了配置資訊（或者不包含）。為了解決這個問題，可以把與微服務相關的配置放在微服務代碼庫裡，然後開放給下層的工具和系統通路。
==微服務層的主要内容==
微服務生态系統的微服務層（第4 層）包含：
- 微服務
- 微服務相關的配置
想及時獲得更多精彩文章，可在微信中搜尋“博文視點”或者掃描下方二維碼并關注。