首先微服務並沒有一個官方的定義，想要直接描述微服務比較困難，我們可以透過對比傳統WEB應用，來理解什麼是微服務。
傳統的WEB應用核心分為業務邏輯、配接器以及API或透過UI訪問的WEB介面。業務邏輯定義業務流程、業務規則以及領域物體。配接器包括資料庫訪問元件、訊息元件以及訪問介面等。一個打車軟體的架構圖如下：
儘管也是遵循模組化開發，但最終它們會打包並部署為單體式應用。例如Java應用程式會被打包成WAR，部署在Tomcat或者Jetty上。
-
開發簡單直接，集中式管理
-
基本不會重覆開發
-
功能都在本地，沒有分散式的管理開銷和呼叫開銷
當然它的缺點也十分明顯，特別對於網際網路公司來說：
-
開發效率低：所有的開發在一個專案改程式碼，遞交程式碼相互等待，程式碼衝突不斷。
-
程式碼維護難：程式碼功能耦合在一起，新人不知道何從下手。
-
部署不靈活：構建時間長，任何小修改必須重新構建整個專案，這個過程往往很長。
-
穩定性不高：一個微不足道的小問題，可以導致整個應用掛掉。
-
擴充套件性不夠：無法滿足高併發情況下的業務需求。
所以，現在主流的設計一般會採用微服務架構。其思路不是開發一個巨大的單體式應用，而是將應用分解為小的、互相連線的微服務。一個微服務完成某個特定功能，比如乘客管理和下單管理等。每個微服務都有自己的業務邏輯和配接器。一些微服務還會提供API介面給其他微服務和應用客戶端使用。
每個業務邏輯都被分解為一個微服務，微服務之間透過REST API通訊。一些微服務也會向終端使用者或客戶端開發API介面。但通常情況下，這些客戶端並不能直接訪問後臺微服務，而是透過API Gateway來傳遞請求。API Gateway一般負責服務路由、負載均衡、快取、訪問控制和鑒權等任務。
微服務架構有很多重要的優點。首先，它解決了複雜性問題。它將單體應用分解為一組服務。雖然功能總量不變，但應用程式已被分解為可管理的模組或服務。這些服務定義了明確的RPC或訊息驅動的API邊界。微服務架構強化了應用模組化的水平，而這透過單體程式碼庫很難實現。因此，微服務開發的速度要快很多，更容易理解和維護。
其次，這種體系結構使得每個服務都可以由專註於此服務的團隊獨立開發。只要符合服務API契約，開發人員可以自由選擇開發技術。這就意味著開發人員可以採用新技術編寫或重構服務，由於服務相對較小，所以這並不會對整體應用造成太大影響。
第三，微服務架構可以使每個微服務獨立部署。開發人員無需協調對服務升級或更改的部署。這些更改可以在測試透過後立即部署。所以微服務架構也使得CI／CD成為可能。
最後，微服務架構使得每個服務都可獨立擴充套件。我們只需定義滿足服務部署要求的配置、容量、實體數量等約束條件即可。比如我們可以在EC2計算最佳化實體上部署CPU密集型服務，在EC2記憶體最佳化實體上部署記憶體資料庫服務。
實際上並不存在silver bullets，微服務架構也會給我們帶來新的問題和挑戰。其中一個就和它的名字類似，微服務強調了服務大小，但實際上這並沒有一個統一的標準。業務邏輯應該按照什麼規則劃分為微服務，這本身就是一個經驗工程。有些開發者主張10-100行程式碼就應該建立一個微服務。雖然建立小型服務是微服務架構崇尚的，但要記住，微服務是達到目的的手段，而不是標的。微服務的標的是充分分解應用程式，以促進敏捷開發和持續整合部署。
微服務的另一個主要缺點是微服務的分散式特點帶來的複雜性。開發人員需要基於RPC或者訊息實現微服務之間的呼叫和通訊，而這就使得服務之間的發現、服務呼叫鏈的跟蹤和質量問題變得的相當棘手。
微服務的另一個挑戰是分割槽的資料庫體系和分散式事務。更新多個業務物體的業務交易相當普遍。這些型別的事務在單體應用中實現非常簡單，因為單體應用往往只存在一個資料庫。但在微服務架構下，不同服務可能擁有不同的資料庫。CAP原理的約束，使得我們不得不放棄傳統的強一致性，而轉而追求最終一致性，這個對開發人員來說是一個挑戰。
微服務架構對測試也帶來了很大的挑戰。傳統的單體WEB應用只需測試單一的REST API即可，而對微服務進行測試，需要啟動它依賴的所有其他服務。這種複雜性不可低估。
微服務的另一大挑戰是跨多個服務的更改。比如在傳統單體應用中，若有A、B、C三個服務需要更改，A依賴B，B依賴C。我們只需更改相應的模組，然後一次性部署即可。但是在微服務架構中，我們需要仔細規劃和協調每個服務的變更部署。我們需要先更新C，然後更新B，最後更新A。
部署基於微服務的應用也要複雜得多。單體應用可以簡單的部署在一組相同的伺服器上，然後前端使用負載均衡即可。每個應用都有相同的基礎服務地址，例如資料庫和訊息佇列。而微服務由不同的大量服務構成。每種服務可能擁有自己的配置、應用實體數量以及基礎服務地址。這裡就需要不同的配置、部署、擴充套件和監控元件。此外，我們還需要服務發現機制，以便服務可以發現與其通訊的其他服務的地址。因此，成功部署微服務應用需要開發人員有更好地部署策略和高度自動化的水平。
-
API Gateway
-
服務間呼叫
-
服務發現
-
服務容錯
-
服務部署
-
資料呼叫
幸運的是，出現了很多微服務框架，可以解決以上問題。
Spring Cloud為開發者提供了快速構建分散式系統的通用模型的工具（包括配置管理、服務發現、熔斷器、智慧路由、微代理、控制匯流排、一次性令牌、全域性鎖、領導選舉、分散式會話、叢集狀態等）。 主要專案包括：
-
Spring Cloud Config：由Git儲存庫支援的集中式外部配置管理。配置資源直接對映到Spring Environment，但是如果需要可以被非Spring應用程式使用。
-
Spring Cloud Netflix：與各種Netflix OSS元件（Eureka，Hystrix，Zuul，Archaius等）整合。
-
Spring Cloud Bus：用於將服務和服務實體與分散式訊息傳遞聯絡起來的事件匯流排。用於在叢集中傳播狀態更改（例如配置更改事件）。
-
Spring Cloud for Cloudfoundry：將您的應用程式與Pivotal Cloudfoundry整合。提供服務發現實現，還可以輕鬆實現透過SSO和OAuth 2保護資源，還可以建立Cloudfoundry服務代理。
-
Spring Cloud – Cloud Foundry Service Broker：提供構建管理一個Cloud Foundry中服務的服務代理的起點。
-
Spring Cloud Cluster：領導選舉和通用狀態模型（基於ZooKeeper，Redis，Hazelcast，Consul的抽象和實現）。
-
Spring Cloud Consul：結合Hashicorp Consul的服務發現和配置管理
-
Spring Cloud Security：在Zuul代理中為負載平衡的OAuth 2休眠客戶端和認證頭中繼提供支援。
-
Spring Cloud Sleuth：適用於Spring Cloud應用程式的分散式跟蹤，與Zipkin，HTrace和基於日誌（例如ELK）跟蹤相容。
-
Spring Cloud Data Flow：針對現代執行時的可組合微服務應用程式的雲本地編排服務。易於使用的DSL，拖放式GUI和REST-API一起簡化了基於微服務的資料管道的整體編排。
-
Spring Cloud Stream：輕量級事件驅動的微服務框架，可快速構建可連線到外部系統的應用程式。使用Apache Kafka或RabbitMQ在Spring Boot應用程式之間傳送和接收訊息的簡單宣告式模型。
-
Spring Cloud Stream Application Starters：Spring Cloud任務應用程式啟動器是Spring Boot應用程式，可能是任何行程，包括不會永遠執行的Spring Batch作業，並且它們在有限時間的資料處理之後結束/停止。
-
Spring Cloud ZooKeeper：ZooKeeper的服務發現和配置管理。
-
Spring Cloud for Amazon Web Services：輕鬆整合託管的Amazon的Web Services服務。它透過使用Spring的idioms和APIs便捷整合AWS服務，例如快取或訊息API。開發人員可以圍繞託管服務，不必關心基礎架構來構建應用。
-
Spring Cloud Connectors：使PaaS應用程式在各種平臺上輕鬆連線到後端服務，如資料庫和訊息代理（以前稱為“Spring Cloud”的專案）。
-
Spring Cloud Starters：作為基於Spring Boot的啟動專案，降低依賴管理（在Angel.SR2後，不在作為獨立專案）。
-
Spring Cloud CLI：外掛支援基於Groovy預言快速建立Spring Cloud的元件應用。
Dubbo是一個阿裡巴巴開源出來的一個分散式服務框架，致力於提供高效能和透明化的RPC遠端服務呼叫方案，以及SOA服務治理方案。其核心部分包含：
-
遠端通訊： 提供對多種基於長連線的NIO框架抽象封裝，包括多種執行緒模型，序列化，以及“請求-響應”樣式的資訊交換方式。
-
叢集容錯：提供基於介面方法的透明遠端過程呼叫，包括多協議支援，以及軟負載均衡，失敗容錯，地址路由，動態配置等叢集支援。
-
自動發現：基於註冊中心目錄服務，使服務消費方能動態的查詢服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。
但是顯而易見，無論是Dubbo還是Spring Cloud都只適用於特定的應用場景和開發環境，它們的設計目的並不是為了支援通用性和多語言性。並且它們只是Dev層的框架，缺少DevOps的整體解決方案（這正是微服務架構需要關註的）。而隨之而來的便是Service Mesh的興起。
Service Mesh又譯作“服務網格”，作為服務間通訊的基礎設施層。如果用一句話來解釋什麼是Service Mesh，可以將它比作是應用程式或者說微服務間的TCP/IP，負責服務之間的網路呼叫、限流、熔斷和監控。對於編寫應用程式來說一般無須關心TCP/IP這一層（比如透過 HTTP 協議的 RESTful 應用），同樣使用Service Mesh也就無須關係服務之間的那些原來是透過應用程式或者其他框架實現的事情，比如Spring Cloud、OSS，現在只要交給Service Mesh就可以了。
-
應用程式間通訊的中間層
-
輕量級網路代理
-
應用程式無感知
-
解耦應用程式的重試/超時、監控、追蹤和服務發現
Service Mesh作為Sidebar執行，對應用程式來說是透明，所有應用程式間的流量都會透過它，所以對應用程式流量的控制都可以在Service Mesh中實現。
目前流行的Service Mesh開源軟體有Linkerd、Envoy和Istio，而最近Buoyant（開源Linkerd的公司）又釋出了基於Kubernetes的Service Mesh開源專案Conduit。
Linkerd是開源網路代理，設計為以服務網格部署：用於管理，控制和監控應用程式內的服務與服務間通訊的專用層。
Linkerd旨在解決Twitter、Yahoo、Google和Microsoft等公司運營大型生產系統時發現的問題。根據經驗，最複雜，令人驚奇和緊急行為的來源通常不是服務本身，而是服務之間的通訊。Linkerd解決了這些問題，不僅僅是控制通訊機制，而是在其上提供一個抽象層。
-
負載平衡：Linkerd提供了多種負載均衡演演算法，它們使用實時效能指標來分配負載並減少整個應用程式的尾部延遲。
-
熔斷：Linkerd包含自動熔斷，將停止將流量傳送到被認為不健康的實體，從而使他們有機會恢復並避免連鎖反應故障。
-
服務發現：Linkerd 與各種服務發現後端整合，透過刪除特定的(ad-hoc)服務發現實現來幫助您降低程式碼的複雜性。
-
動態請求路由：Linkerd 啟用動態請求路由和重新路由，允許您使用最少量的配置來設定分段服務（staging service），金絲雀（canaries），藍綠部署（blue-green deploy），跨DC故障切換和黑暗流量（dark traffic）。
-
重試次數和截止日期：Linkerd可以在某些故障時自動重試請求，並且可以在指定的時間段之後讓請求超時。
-
TLS：Linkerd可以配置為使用TLS傳送和接收請求，您可以使用它來加密跨主機邊界的通訊，而不用修改現有的應用程式程式碼。
-
HTTP代理整合：Linkerd可以作為HTTP代理，幾乎所有現代HTTP客戶端都廣泛支援，使其易於整合到現有應用程式中。
-
透明代理：您可以在主機上使用iptables規則，設定透過Linkerd的透明代理。
-
gRPC：Linkerd支援HTTP/2和TLS，允許它路由gRPC請求，支援高階RPC機制，如雙向流，流程控制和結構化資料負載。
-
分散式跟蹤：Linkerd支援分散式跟蹤和度量儀器，可以提供跨越所有服務的統一的可觀察性。
-
儀器儀錶：Linkerd支援分散式跟蹤和度量儀器，可以提供跨越所有服務的統一的可觀察性。
Envoy是一個面向服務架構的L7代理和通訊匯流排而設計的，這個專案誕生是出於以下標的：
對於應用程式而言，網路應該是透明的，當發生網路和應用程式故障時，能夠很容易定位出問題的根源。
-
外接行程架構：可與任何語言開發的應用一起工作；可快速升級。
-
基於新C++11編碼：能夠提供高效的效能。
-
L3/L4過濾器：核心是一個L3/L4網路代理，能夠作為一個可程式設計過濾器實現不同TCP代理任務，插入到主服務當中。透過編寫過濾器來支援各種任務，如原始TCP代理、HTTP代理、TLS客戶端證書身份驗證等。
-
HTTP L7過濾器：支援一個額外的HTTP L7過濾層。HTTP過濾器作為一個外掛，插入到HTTP連結管理子系統中，從而執行不同的任務，如緩衝，速率限制，路由/轉發，嗅探Amazon的DynamoDB等等。
-
支援HTTP/2：在HTTP樣式下，支援HTTP/1.1、HTTP/2，並且支援HTTP/1.1、HTTP/2雙向代理。這意味著HTTP/1.1和HTTP/2，在客戶機和標的伺服器的任何組合都可以橋接。
-
HTTP L7路由：在HTTP樣式下執行時，支援根據content type、runtime values等，基於path的路由和重定向。可用於服務的前端／邊緣代理。
-
支援gRPC：gRPC是一個來自谷歌的RPC框架，使用HTTP/2作為底層的多路傳輸。HTTP/2承載的gRPC請求和應答，都可以使用Envoy的路由和LB能力。
-
支援MongoDB L7：支援獲取統計和連線記錄等資訊。
-
支援DynamoDB L7：支援獲取統計和連線等資訊。
-
服務發現：支援多種服務發現方法，包括非同步DNS解析和透過REST請求服務發現服務。
-
健康檢查：含有一個健康檢查子系統，可以對上游服務叢集進行主動的健康檢查。也支援被動健康檢查。
-
高階LB：包括自動重試、斷路器，全域性限速，阻隔請求，異常檢測。未來還計劃支援請求速率控制。
-
前端代理：可作為前端代理，包括TLS、HTTP/1.1、HTTP/2，以及HTTP L7路由。
-
極好的可觀察性：對所有子系統，提供了可靠的統計能力。目前支援statsd以及相容的統計庫。還可以透過管理埠檢視統計資訊，還支援 第三方的分散式跟蹤機制。
-
動態配置：提供分層的動態配置API，使用者可以使用這些API構建複雜的集中管理部署。
Istio是一個用來連線、管理和保護微服務的開放平臺。Istio提供一種簡單的方式來建立已部署服務網路，具備負載均衡、服務間認證、監控等功能，而不需要改動任何服務程式碼。想要為服務增加對Istio的支援，您只需要在環境中部署一個特殊的邊車（sidecar），使用Istio控制面板功能配置和管理代理，攔截微服務之間的所有網路通訊。
Istio目前僅支援在Kubernetes上的服務部署，但未來版本中將支援其他環境。
Istio提供了一個完整的解決方案，透過為整個服務網格提供行為洞察和操作控制來滿足微服務應用程式的多樣化需求。它在服務網路中統一提供了許多關鍵功能：
-
流量管理：控制服務之間的流量和API呼叫的流向，使得呼叫更可靠，並使網路在惡劣情況下更加健壯。
-
可觀察性：瞭解服務之間的依賴關係，以及它們之間流量的本質和流向，從而提供快速識別問題的能力。
-
策略執行：將組織策略應用於服務之間的互動，確保訪問策略得以執行，資源在消費者之間良好分配。策略的更改是透過配置網格而不是修改應用程式程式碼。
-
服務身份和安全：為網格中的服務提供可驗證身份，並提供保護服務流量的能力，使其可以在不同可信度的網路上流轉。
Conduit是為Kubernetes設計的一個超輕型服務網格服務，它可透明地管理在Kubernetes上執行的服務的執行時通訊，使得它們更安全可靠。Conduit提供了可見性、可靠性和安全性的功能，而無需更改程式碼。
Conduit service mesh也是由資料面板和控制面板組成。資料面板承載應用實際的網路流量。控制面板驅動資料面板，並對外提供北向介面。
Linkerd和Envoy比較相似，都是一種面向服務通訊的網路代理，均可實現諸如服務發現、請求路由、負載均衡等功能。它們的設計標的就是為瞭解決服務之間的通訊問題，使得應用對服務通訊無感知，這也是Service Mesh的核心理念。Linkerd和Envoy像是分散式的Sidebar，多個類似Linkerd和Envoy的proxy互相連線，就組成了Service Mesh。
而Istio則是站在了一個更高的角度，它將Service Mesh分為了Data Plane和Control Plane。Data Plane負責微服務間的所有網路通訊，而Control Plane負責管理Data Plane Proxy：
並且Istio天生的支援Kubernetes，這也彌合了應用排程框架與Service Mesh之間的空隙。
關於Conduit的資料較少，從官方介紹看它的定位和功能與Istio類似。
Kubernetes + Service Mesh = 完整的微服務框架
Kubernetes已經成為了容器排程編排的事實標準，而容器正好可以作為微服務的最小工作單元，從而發揮微服務架構的最大優勢。所以我認為未來微服務架構會圍繞Kubernetes展開。而Istio和Conduit這類Service Mesh天生就是為了Kubernetes設計，它們的出現補足了Kubernetes在微服務間服務通訊上的短板。雖然Dubbo、Spring Cloud等都是成熟的微服務框架，但是它們或多或少都會和具體語言或應用場景系結，並只解決了微服務Dev層面的問題。若想解決Ops問題，它們還需和諸如Cloud Foundry、Mesos、Docker Swarm或Kubernetes這類資源排程框架做結合：
但是這種結合又由於初始設計和生態，有很多適用性問題需要解決。
Kubernetes則不同，它本身就是一個和開發語言無關的、通用的容器管理平臺，它可以支援執行雲原生和傳統的容器化應用。並且它改寫了微服務的Dev和Ops階段，結合Service Mesh，它可以為使用者提供完整端到端的微服務體驗。
所以我認為，未來的微服務架構和技術棧可能是如下形式：
多雲平臺為微服務提供了資源能力（計算、儲存和網路等），容器作為最小工作單元被Kubernetes排程和編排，Service Mesh管理微服務的服務通訊，最後透過API Gateway向外暴露微服務的業務介面。
我相信未來隨著以Kubernetes和Service Mesh為標準的微服務框架的盛行，將大大降低微服務實施的成本，最終為微服務落地以及大規模使用提供堅實的基礎和保障。
-
https://www.nginx.com/blog/introduction-to-microservices/
-
http://microservices.io/patterns/microservices.html
-
https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes/
-
https://istio.io/
-
https://www.envoyproxy.io/
-
https://linkerd.io/
-
https://yq.aliyun.com/articles/2764
-
http://istio.doczh.cn/
-
http://linkerd.doczh.cn/
原文連結：https://xiaoxubeii.github.io/articles/microservices-architecture-introduction/
本次培訓內容包括：Docker容器的原理與基本操作；容器網路與儲存解析；Kubernetes的架構與設計理念詳解；Kubernetes的資源物件使用說明；Kubernetes 中的開放介面CRI、CNI、CSI解析；Kubernetes監控、網路、日誌管理；容器應用的開發流程詳解等，點選識別下方二維碼加微信好友瞭解具體培訓內容。
3月23日開始上課，最後8個名額，點選閱讀原文連結即可報名。
長按二維碼向我轉賬
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球
