在PC剛剛流行起來的時代，各種配件的標準化還不夠好，各品牌廠商還沒有完善的整機組裝體系及時輸出質量可靠產品，當時盛行的是大家購買各種配件自行DIY，網絡上、期刊上充斥著各種DIY的經驗。這與微服務架構當前的發展何其相似。

同樣，本文也是在嘗試梳理微服務DIY的經驗。

微服務漫談

當年Spring 是以IoC為核心快速的在業務層一統天下，成功地踩著J2EE的肩膀上位，而今天，微服務跟Bean對象是兩個完全不同量級的存在，如果說Bean對象是地球，微服務就是太陽系。微服務是縱跨網絡通信，邏輯處理，存儲，系統和硬件等所有層的。駕馭微服務要比駕馭Bean對象複雜的多。

同時，微服務的時代，沒有巨人的肩膀可以踩，Spring Cloud也只能是借鑑著Netflix的經驗摸著石頭過河，希望快速完善自己的微服務體系，保持自己這條大船繼續領先。所以，對待Spring Boot/Cloud要以批判而不是盲目崇拜的的心態去應用它。

Netflix在微服務的實踐上是成功的，但Netflix的成功並不代表著所有人重走Netflix的路也能成功。總的來說，業界能夠達成一致的是，微服務作為一個最小單元，在實踐過程中需要面對以下問題：

• 服務拆分（基於業務功能，基於領域的子域）

• 配置管理及Secret管理

• API網關

• 通信（HTTP/REST，gRPC，Thrift，消息/Message Broker，領域獨用協議（流媒體RTMP, HLS, 和 HDS））

• 服務發現與負載平衡（服務註冊表，客戶端服務發現與負載均衡，服務器端服務發現與負載均衡，服務自注冊，服務第三方註冊）

• 事件驅動（事件溯源CQRS，事務日誌跟蹤，數據庫觸發器，應用程序事件）

• 日誌集中

• 指標度量

• 分佈式追蹤

• 健康檢查

• 故障隔離與斷路器

• 服務安全（訪問令牌）

• 服務部署

• 服務的自動伸縮與修復

在DC/OS上實踐微服務

面對如此眾多而又複雜的交互，要真正成功的實踐微服務不是一件容易的事情。微服務的複雜性決定了其對方案設計，過程管控和承載環境有極高的要求。下面來看DC/OS在微服務架構實踐的各個方面的適應性。

承載環境

微服務的實例數量受業務的複雜性，服務拆分的粒度和服務的訪問壓力等許多因素影響，業務越複雜，訪問壓力越大，拆分粒度越小，則微服務的實例數會越多，通常都會有數十或者成百上千甚至更多。

面對如此龐大的服務實例數，固定的承載環境（指定哪臺或哪些臺節點部署哪些基礎中間件或服務）一定是一種最差的選擇。

固定的承載環境意味著要預先為服務做出資源的規劃，而運營過程中資源故障，短缺等都會對服務產生影響。

同時，固定的承載環境一定會需要自動化的工具來操縱如此多的服務實例的部署，而增加自動化部署工具就需要工具適應服務的多樣性，底層資源的多樣性和網絡的不可靠性等，不僅增加了環節還增加了實施的難度。

動態的承載環境（服務或基礎中間件在節點之間是可以動態遷移），服務的實例是按需分配資源的，分配的資源節點出現故障時，服務實例可以動態遷移到其他資源節點上，只要資源總池還有空閒資源，服務的資源就不會短缺。既然資源對每一個服務實例來說都是等同的，服務實例只需要複製即可橫向擴展，反之，可以收縮。

服務的存在形式是有差異性的，不同的技術體系實現的服務各不相同。非標準化的服務與動態資源的對接會非常複雜，因此，需要將服務的存在形式標準化，而容器技術的出現正好解決了這一問題。容器內部承載的服務是不規則，非標準化的，容器對動態的承載環境來說又是標準的。

所以，要實踐微服務架構設計，一定要選擇容器技術。

當前Docker是容器技術的事實標準，DC/OS為容器提供了強大的動態承載環境。

• 通過內置的Marathon對容器進行動態編排和故障遷移。

• 通過Mesos以資源池的形式為容器提供按需配置的資源。

過程管控

單體應用時代，應用的開發會採用模塊化實現並最終聚合輸出。微服務時代，每一個微服務仍然採用模塊化實現，但聚合起來的只是單一的一個微服務。前述說過，微服務的數量受業務的複雜性和拆分粒度影響，服務數量動輒成百上千。

如果將每一個微服務看做是一條生成線，現在就變成了成百上千條生產線同時開工，儘管每條生產線上的員工少了，但其管理與單條生產線的管理完全不同。會涉及到總體調度，環節把控與效率等全新的課題。

解決微服務實踐在過程管控方面的方案是最大程度的引入自動化。容器技術彌合了Dev與Ops之間的鴻溝，大大降低了DevOps的實施難度。

當前討論DevOps的文章網上隨處可見。不必求大求全，先建骨架，運轉起來，然後再根據自己的場景，結合實踐，進行精細化雕琢。

下面是一種DevOps骨架：

關於DevOps的論述，請參考《軟件領域修煉之過程，也談DevOps》和《56張圖片來自近50家公司的DevOps及CICD架構》。

所以，要實踐微服務架構設計，一定要採用DevOps。

DC/OS為DevOps和CI/CD提供了一鍵式部署方案，包括Jenkins，Gitlab，Nexus（Artifactory）和Registry等。在DC/OS中使用Docker鏡像倉庫的方案有多種，既可以使用Nexus，Artifactory，也可以使用原廠Docker Registry。

可以通過Marathon實現Zero-down Deployment（零宕機）部署。可以通過Vamp等框架實現藍-綠部署，Canary部署等。

方案設計

方案設計是當前大多數人關注的焦點，因為，在未對微服務架構有全局性的認知之前，這是微服務實踐的起點。

前述說過，微服務是縱跨網絡通信，邏輯處理，存儲，系統和硬件等所有層的。如果拋開前述微服務眾多的關注點不管，微服務的業務開發與面向服務的SOA沒什麼不同。

但是，因為拆分，原先服務模塊內部的連接變成了微服務外部的互連。微服務就像是一個形狀不規則的積木，有太多的面可以交互，在不同的的設計者手裡就有了不同的玩法。

下面我們逐個來看微服務方案設計相關的關注點，關於微服務方案設計的模式和最新趨勢可跟蹤Chris Richardson 的微服務架構網站（http://microservices.io/index.html）。

服務拆分

微服務的服務拆分沒有固定的標準，因為微服務是現實世界業務邏輯的一個映射，不同的人針對不同的環境有不同的理解，同時還要考量技術、複雜度和團隊等其他因素。雖然沒有固定的標準，服務拆分還是有一些指導性的原則，如單一職責原則，基於業務功能拆分或基於領域的子域拆分等。

配置管理及Secret管理

在單體應用架構設計中，配置是集中式的。而面對眾多的微服務及成倍的微服務實例，配置管理就成為一個新的關注點。與此同時，對於配置中的敏感信息，也是成倍的擴散，需要特別關注。

當前配置管理的解決方案主要是通過集中式的配置管理實現，如Zookeeper，Etcd，Consul等，由服務實例主動拉取配置。對於需要跟蹤的配置，可通過Git倉庫進行版本管理，在配置變更時推送到配置管理服務端，然後再由服務實例定時拉取應用配置。

對於敏感的配置信息，如數據庫訪問密碼，API令牌等，需要加密存放，因此需要Secrets管理服務。當前可選的方案是通過Vault存放敏感信息。

DC/OS企業版支持配置管理和Secrets管理，在開源的社區版版本中：

• 通過Zookeeper/Etcd存儲配置

• 通過Vault存放敏感信息

• 使用Gitlab跟蹤配置變更

• 針對微服務實現，Spring Boot/Cloud支持從Zookeeper配置，Spring Vault項目可以讀取Secrets配置

• 針對微服務實現，也可以使用Cfg4j進行配置應用處理

API網關

微服務最為明顯的特徵就是服務的數量多而分散。對於這些離散的服務，必定需要考慮一些共性的東西，如安全，流量限制等，在Bean框架時代，通過AOP可以分離關注點，在微服務架構中就需要API網關擔負起這些職責。

API網關的主要職責是提供統一的服務入口，讓微服務對前端透明，並提供路由，緩存，安全，過濾，流量控制等管理功能。API網關的實現方式有多種，Spring的Zuul 和 Netflix的API網關都是常見的實現，基於Nginx擴展也是常見的一種實現方式，KONG就是在Nginx和OpenResty之上通過Lua腳本擴展實現的一種API網關。

KONG提供了API支持用戶自定義插件擴展，並實現了眾多的插件支持API網關的職能，如：認證（HTTP基本認證，密鑰認證，OAuth，JWT，HMAC和LDAP），安全（ACL，CORS（ Cross-origin Resource Sharing，跨域資源共享），動態SSL，IP限定和機器人偵測），流量控制（請求限流，請求響應限流，請求載荷限定），分析與監控，數據轉換（請求轉換，響應轉換，請求/響應關聯），日誌記錄等功能。

KONG也存在於DC/OS的Universe倉庫中，可以一鍵部署。

通信

微服務之間的通信可以通過HTTP/REST，gRPC，Thrift，消息/Message Broker，領域獨用協議（流媒體RTMP, HLS, 和 HDS）等多種方式，具體需要根據應用場景進行決策。

Linkerd支持基於HTTP1.1，HTTP2，gRPC，Thrift等的服務代理，重試，超時，斷路保護，負載均衡和服務發現等。

Linkerd支持DC/OS中一鍵部署集成。

服務發現與負載平衡

服務發現與負載均衡有多種方案可供選擇。通常包含一個服務註冊表，採用服務自注冊或者服務第三方註冊的方式。在請求服務時，可以採用客戶端服務發現與負載均衡或者服務器端服務發現與負載均衡兩種模式。

服務註冊表的實現有多種選擇，如Netflix的Eureka，國內常用的Dubbo/Dubbox，也可以使用Zookeeper，Etcd和Consul實現。

Netflix的Ribbon使用客戶端發現方式，可以使用Netflix Prana代理微服務進行第三方註冊，使用Feign為微服務客戶端調用提供負載均衡。

DC/OS也為服務發現和負載均衡提供了多種選擇，如VIP，Mesos-DNS，Marathon-LB等。也可以選擇Linkerd。

Linkerd是一種比較特殊的實現思路，它以服務網格（Service Mesh）的設計對兩個微服務之間的調用進行職責分離，與服務調用相關的服務發現，負載均衡，超時，重試，斷路保護和服務跟蹤等職責都由它來代理。

事件驅動

在微服務架構中面臨的另一個重要問題就是跨服務的分佈式一致性。分佈式一致性是大家所熟知的分佈式設計必須面對的問題，在數據庫層面提到的更多一些，如CAP理論。

在微服務層面，業務數據的分佈式一致性也有多種方案，如事件溯源CQRS，事務日誌跟蹤，數據庫觸發器，應用程序事件等。

Lightbend的Lagom是基於事件溯源CQRS實現的微服務框架。

日誌集中

DC/OS支持ELK解決方案，其他的方案也可以自行構建。

指標度量

指標度量Metrics這個概念在軟件應用體系中所扮演的角色越來越重要。在微服務架構體系中，數量龐大的微服務在運行過程中，通過Metrics可以準確把握其當前的運行態勢。Metrics的歸集，分析展現和報警也是微服務實踐的重要一環。

DC/OS支持Prometheus，Grafana作為服務、容器及系統多個層面的Metrics度量和監控報警。

分佈式追蹤

在業務層面，一次業務往往需要橫跨多個離散的服務，而每個服務同時有多個服務實例在運行，如何知道一次業務事務處理流經了哪些服務的哪些實例？如果事務出現異常，如何快速定位？這就是微服務分佈式追蹤所要解決的問題。

微服務的分佈式追蹤可以採用Zipkin，大眾點評CAT，Linkerd等方案。Spring通過Spring Cloud Sleuth封裝了Zipkin。

可以在DC/OS中部署Zipkin和CAT的服務器端。Linkerd支持DC/OS的部署集成。

健康檢查

DC/OS中的Marathon支持服務的健康檢查。可以通過TCP，HTTP，HTTPS，COMMAND等多種手段檢查服務是否健康。健康檢查是服務跟蹤，服務動態部署和自動故障遷移的基礎。

故障隔離與斷路器

常見的斷路器解決方案是Netflix的Hystrix。Linkerd也支持斷路器和故障隔離。

Linkerd支持DC/OS中一鍵部署集成。

總結

本文通過微服務架構實踐涉及的方案設計，過程管控和承載環境三個方面詳細的闡述了微服務的實踐要求及DC/OS或其之上的服務框架給出的應對方案，供大家在實踐微服務架構時參考。

上述解決方案中的Prometheus和Linkerd都是CNCF聯盟的成員項目。