java微服務生態系統模型解讀
微服務并不是孤立存在的，它們存在于一個環境里，微服務在這個環境里進行交互。把這種環境看成微服務生態系統并分層，有助于理解微服務架構。
在一個設計良好的微服務生態系統里，微服務與基礎設施之間是分離的。微服務與硬件、網絡、構建和部署管道、服務發現和負載均衡都是分離的。它們都是微服務生態系統基礎設施的組成部分。如何以一種穩定可靠的、可伸縮的、可容錯的方式來構建、維護和標準化基礎設施，是微服務運維的根本。
基礎設施必須能夠支撐微服務生態系統。基礎設施工程師和架構師的共同目標是為微服務的開發工作隱藏底層的運維細節，并構建一個穩定的、可伸縮的基礎設施平臺，讓開發者可以輕松地在上面構建和運行微服務。在一個穩定的微服務生態系統里開發一個微服務應該跟開發一個小型的標準應用一樣，都需要一個出類拔萃的基礎設施的支持。
微服務生態系統可以被分為4 層，雖然層與層之間的邊界不一定都很清晰，但這些層會涉及基礎設施的幾個元素。底下的3 層是基礎設施層：最下面的是硬件層，其次是通信層（一直滲透到第4 層），緊接著的是應用平臺層。第4 層（頂層）就是微服務所在的層。
微服務生態系統的4層模型
第1 層：硬件層
微服務生態系統的底層是硬件層。這一層是服務器物理機所在的層，它們是所有內部工具和微服務運行的基礎。這些服務器被放置在數據中心的機架上，由供電系統供給電力，使用著昂貴的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 層是通信層。通信層滲透到生態系統的所有層（包括應用平臺層和微服務層），因為微服務之間的交互會在多個層上進行，所以很難清晰地對通信層與其他層之間的邊界進行定義。雖然難以清晰地定義它們之間的邊界，但是這個層所涉及的元素是很明確的。第2 層一般包含網絡、DNS、RPC 和API 端點、服務發現、服務注冊以及負載均衡。
有關通信層網絡和DNS 元素的內容已經超出了本文的范疇，在這里，我們主要討論RPC、API 端點、服務發現、服務注冊和負載均衡。
RPC、端點和消息傳遞
微服務通過遠程過程調用（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 層：應用平臺層
應用平臺層是微服務生態系統的第3 層，這一層包含了所有獨立于微服務的內部工具和服務。這一層所包含的集中式的工具和服務跨越了整個生態系統，因為有了這些工具和服務，微服務開發團隊就可以把精力集中在微服務的開發上。
一個好的應用平臺需要為開發者提供一套內部的自助工具，包括標準化的開發流程、集中式的自動化構建和發布系統、自動化測試、標準化和集中式的部署方案以及集中式的日志和微服務級別的監控。這些元素的細節此處不進行探討，不過我們也會簡要地介紹其中的幾個元素，闡述一些基本的概念。
內部自助開發工具
有很多東西可以被納入內部自助開發工具的范疇，它們是否可以被歸為這類工具不僅取決于開發者對工具的需求，還要考慮基礎設施和生態系統的整體抽象度和復雜性。決定使用哪一種工具，首先要對責任領域進行切分，然后對開發者所要完成的任務進行評估，以便設計、構建和維護他們的服務。
在一個已經使用了微服務架構的公司里，給工程團隊指派職責要十分謹慎。最簡單的做法是為微服務生態系統的每一個層組建一個工程子團隊。這些工程子團隊將負責處理它們所在層的所有相關事務：運維團隊負責第1 層，基礎設施團隊負責第2 層，應用平臺團隊負責第3 層，微服務團隊負責第4 層（這看起來很簡單，只要你能明白就好了）。
在這種組織結構里，工作在上層的工程師需要使用自助工具對下層的一些東西進行配置。例如，負責消息服務的團隊應該為其他開發者提供一個自助工具，當微服務團隊的開發者需要為他們的服務配置消息系統時，他們就可以使用這個工具，而無須過多地了解紛繁復雜的消息系統。
使用這些集中式的自助工具是有原因的。在一個多元化的微服務生態系統里，一個團隊的普通工程師對其他團隊的系統和服務并不了解（或知之甚少），他們也不可能成為面面俱到的專家。每個開發人員只對自己負責的部分比較了解，但從整個生態系統來看，這些開發人員組合在一起就無所不知了。為生態系統的每一部分構建易用的用戶界面，為開發人員提供相關的培訓，以便教會他們如何使用這些工具，而不是試圖讓每個開發人員了解這些工具和服務紛繁復雜的內部細節。把所有的事情放到一個黑匣子里，然后提供詳細的說明文檔。
使用這些工具的第二個理由是，你不需要其他團隊的人來對你的服務和系統做任何關鍵性的改動，因為這些人可能會給你們帶來麻煩。對于底層（第1 層、第2 層和第3 層）的服務和系統來說，更是如此。讓他們在這些層上面做出改動，或者要求（更糟糕的是期待）他們成為某方面的專家有可能會釀成大禍。舉一個配置管理的例子：不具備相關專門知識的微服務團隊開發人員對系統配置做了一些變更，這有可能導致大規模的服務癱瘓，因為他們所做的變更有可能不只是影響到他們自己的服務。
開發周期
開發人員在對已有微服務進行修改或構建新的微服務時，對開發流程進行流水線化、標準化和自動化可以大幅提升開發效率。對開發流程進行標準化將在第4 章進行探討。有些東西需要被放在微服務生態系統的第3 層，讓穩定可靠的開發成為可能。
首先是集中式的版本控制系統，這個系統保存了所有代碼，允許對代碼進行跟蹤、版本管理和搜索。這個可以通過一些工具來實現，比如GitHub 或者自有的git 或svn 代碼倉庫，可以將這些倉庫和一些協作工具集成起來，比如Phabrictor，以簡化代碼的維護和審查工作。
其次是穩定高效的開發環境。眾所周知，在微服務生態系統里實現一個這樣的開發環境是很困難的，因為微服務之間的依賴太過復雜。不過它們都是最基本的因素，我們無法避免。一些工程組織傾向于在本地完成開發工作（在開發人員的電腦上），不過這樣會導致糟糕的部署，因為開發人員并不清楚他們修改的代碼是如何被部署到生產環境的。最穩定可靠的構建開發環境的方式是為生產環境創建一個鏡像（不是為了預生產，也不是為了收集反饋，更不是為了生產），這個鏡像包含所有復雜的依賴關系鏈。
測試、構建、打包和發布
開發過程中的測試、構建、打包和發布應該盡量被標準化和集中化。在開發結束之后，當有代碼變更被提交，需要運行相關的測試用例，然后自動構建和打包即將發布的新版本。這個時候，持續集成工具就可以派上用場，一些現成的解決方案（比如Jenkins）不僅功能齊全而且使用方便。這些工具可以讓整個過程自動化，幾乎不留給人類任何犯錯的機會。
部署管道
在經過了開發、測試、構建、打包和發布這些步驟之后，部署管道是新代碼走向生產環境的另一個流程。在一個微服務生態系統里，部署會在很短的時間內變得極其復雜，每天上百個部署都是很平常的事。開發團隊需要為開發構建工具，并對開發過程進行標準化。
日志和監控
所有的微服務都應該把與它們的請求和響應相關的重要信息記錄到日志里。因為微服務變更的速度太快，如果系統發生了錯誤，重建當時的系統狀態變得很困難，導致代碼的缺陷難以重現。使用微服務級別的日志可以幫助開發人員更好地了解他們的服務在過去某個時刻或當前時刻的狀態。在微服務級別對微服務的關鍵度量指標進行監控也是出于同樣的目的：實時準確的監控可以幫助開發人員了解服務的狀態和健康狀況。
微服務生態系統的應用平臺層（第3 層）包含：
- 內部自助開發工具
- 開發環境
- 測試、構建、打包和發布工具
- 部署管道
- 微服務級別的日志
- 微服務級別的監控
第4 層：微服務層
微服務生態系統的頂層是微服務層（第4 層）。這一層是微服務以及微服務所有相關事物所在的層，它與底下的基礎設施層完全分離，比如硬件、部署、服務發現、負載均衡和通信。微服務層唯一沒有被分離的是使用自助工具所做的配置。
在軟件工程里，應用的配置一般會被集中化，針對某個工具或某些工具（配置管理、資源隔離或部署工具）的配置可以和這些工具保存在一起。例如，應用程序的自定義部署配置一般會和部署工具的代碼保存在一起，而不是和應用程序的代碼保存在一起。這種方式對單體應用架構或小型的微服務生態系統來說是沒有問題的，但在包含了大量微服務和內部工具（每個工具都有自定義的配置）的大型微服務生態系統里，這種方式就會造成混亂：處在上層的微服務團隊需要修改處在下層的工具代碼，他們會經常忘記哪些地方包含了配置信息（或者不包含）。為了解決這個問題，可以把與微服務相關的配置放在微服務代碼庫里，然后開放給下層的工具和系統訪問。
==微服務層的主要內容==
微服務生態系統的微服務層（第4 層）包含：
- 微服務
- 微服務相關的配置
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%