如何分析基于容器的微服務架構技術選型與設計，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
作為金融企業，國投瑞銀基金多年以來 IT 工作主要還是以運維為主，主要業務系統基本采用外購模式，但隨著業務的不斷發展，業務部門個性化需求越積越多，外購與外包已經不能很好滿足業務員部門的需要了。2016 年底公司著手開發團隊的組建工作，同時對公司的業務開發平臺進行架構選型與設計，以求統一開發平臺，提升研發效率，從而加快業務部門的業務需求處理效率。
下面我們將就這兩年在平臺架構選型、平臺架構設計、平臺及相關子系統的逐步完善背后的一些經驗進行分享。
該架構全部基于開源平臺，經過三年多的生產上線實踐，平臺運行平穩，可擴展性強，可用性高，可以很好滿足公司對于金融業務不斷發展的需要，這對類似的中小型企業的業務架構選型也具有一定的參考意義。
注：UFOS：國投瑞銀基金運營系統
在初期平臺架構設計與選型時，我們根據現有業務系統的需求，梳理出了技術架構選型需要考量關鍵因素：
架構平臺的前瞻性或先進性，符合當前潮流與未來發展趨勢，有較好的生態鏈和較強的生命力，不能因為平臺架構選型不當，導致未來平臺重新架構，造成大量的遷移和重構工作，需保障平臺架構能在一段時間內保持技術領先。
這里有兩點注意，一是對技術成熟度的考量，是否采用有風險的前沿技術以及擁抱這種技術帶來的風險，這一點類似于金融投資中收益與風險的關系，我們需要在系統的先進性與系統的穩定性之間進行平衡；二是采用前沿技術可能會面對更多的困難，如國內可能缺乏相關資料，或難以找到可以參考的成功案例，很多時候只能通過官方和論壇獲取相關技術信息，會對架構按時交付帶來風險。
平臺的可擴展性
能滿足基金行業業務不斷的發展與創新的需求，盡量能做到平臺的橫向平滑擴展，滿足以上特性其實就決定了架構的分布式特性，當然我們更希望它是云原生的架構
系統的可靠性和可用性
作為金融業務系統平臺，需保證業務系統連續不間斷運行，保證平臺的高可用。采用集群或平臺自動恢復功能，確保平臺局部出錯也不影響系統整體的運行；這里有兩個層面，一是業務系統中的功能組件能相互隔離，其中一個組件的不可用不能影響到系統的其他部分；二是平臺基礎系統采用集群架構，有自動恢復功能，確保即使系統中有節點出錯，也可在很短時間內完成出錯節點中服務的切換與恢復
開銷
不同的架構 / 技術選擇有著不同的開發成本，包括技術框架，平臺的學習成本，我們期望平臺能支持異構的技術，使得開發人員可以采用比較適合的技術棧來快速實現業務功能的開發
開發運維一體化思想（ DevOps ），在設計時考慮運維，盡量減少后期運維操作的復雜度，減輕后期業務系統運維的負擔。
讓開發人員更多專注在業務功能需求開發，其它非功能需求如負載均衡、高可用等盡量由平臺提供，做到對開發人員透明，以提升開發效率。
當公司規模不大，實力不足以自己實現部分或全部架構，選擇現成的“輪子”來組裝自己的架構就成了一種自然的選擇。在選擇上可能會更多考慮如何使用更“標準”的“輪子”來滿足自己業務的需求，以便于今后業務的升級和擴展。
要實現上述平臺的擴展性和高可用性，一般都離不開分布式架構，而分布式架構一般離不開服務來承載 。
基于服務的架構設計早已有之，比如基于 RPC 的服務調用，最早可追溯到 CORBA，以及現在還有很多金融公司在交易系統中使用的 BEA 早期的框架 Tuxedo（主要編程語言為 C/C++）。后來者有 Facebook 的 Thrift，Google Protocolbuf 框架 /grpc，阿里的 Dubbo 框架等等。這些框架支持消息的二進制編碼（序列化與反序列化），效率高，因此成了對網絡傳輸，并發處理要求高的應用如 App 應用，游戲，交易軟件等的首選。
后來隨著 HTTP 協議的廣泛應用，發展衍生出面向服務的架構（SOA）的架構設計，該架構一般都應用在比較復雜，大型項目中，為了異構系統中的功能復用，或系統性能的考量將功能模塊獨立出來成為服務，服務可以分布式部署，服務之間通過標準的軟件接口方式在網絡中相互調用；為了統一服務調用標準，SOA 往往還引入了數據總線概念，服務可以通過數據總線進行服務注冊，服務的查找與調度。
SOA 架構中的服務之間是松耦合的，服務的顆粒度相對比較粗，而近些年出現的微服務，則可以看作是對 SOA 服務的一種精簡，細化，或者說是 SOA 服務的輕量版。
在談及微服務的時候，大都會對應到單體應用，以示鮮明對比；單體應用其實就是一個服務中包含了太多種功能的應用，它跟面向對象的設計里的單體類（包含太多功能實現的類）的提法頗有些類似，英文單詞中有一個專有名詞 monolithic 來描述二者：
如果你再仔細對照微服務和類，你會發現兩者有諸多相似之處，比如微服務和類在設計原則上也是一致的，也就是高內聚 / 封裝與松耦合，高內聚也就是只負責一項任務，也就是單一職責原則，而松耦合則是指模塊之間的接口盡量簡單，減少耦合度，這樣也使得開發，獨立部署和升級微服務更加容易。
微服務除了內部相互之間調用和通信之外，最終要以某種方式暴露出去，才能讓外界系統（例如 Web 應用、移動應用等）訪問到，這就涉及服務的前端路由，它是連接內部微服務和外部應用系統的一個通道。
HaProxy 與 Ngix 等工具也可以實現 HTTP 反向代理，但基于以下特性，開源的 HTTP 反向代理與負載均衡工具 Traefik 成為我們的最終選擇：
Traefik 更適合需要服務發現和服務注冊的應用場景，它 支持多種后臺應用自動發現，如 Docker，Swarm，Kubernetes，Consul 等，它還可以動態監測后臺服務的變動以自動實時更新自己的配置。
支持限流與自動熔斷功能。
支持配置熱更新。
可以說 Traefik 非常適合容器化的微服務，采用 Traefik 可以帶來以下好處：
服務反向路由，Traefik 將外部請求反向路由到內部具體的微服務，這樣雖然系統平臺內部是復雜的分布式微服務架構，但是外部系統從代理上看到的就像是一個統一的完整服務，代理屏蔽了后臺服務的復雜性（類似 Facade 模式），同時也可以屏蔽后臺服務的升級和變化。
便于安全控制，服務通過代理統一訪問后端的微服務，而代理訪問微服務是通過容器內部網絡進行，也就是微服務都可以不用暴露端口到容器外端，外部應用也就不能直接訪問容器里邊的微服務了，而必須通過 Traefik 代理。代理有微服務的注冊信息，它可以根據微服務名正確路由到相應的 IP/ 端口的微服務容器。這樣我們的安全策略就只需要集中在 Traefik 代理端控制即可。
提供多種格式度量數據，比如可以提供我們采用的 Prometheus 監控數據格式，提供訪問量，調用延遲，錯誤計數等數據，為后端的性能優化或者擴容提供數據支持。
在我們的架構選型中，我們選擇了流行的開源框架 ELK 棧；日志寫入遠端的 Elasticsearch，通?？梢圆捎脙煞N方式，一種方式是通過日志代理，如 Elasticsearch 提供的高效的 Beats 工具，可以將 Beats 與業務服務部署在一起，這適合第三方服務（沒有源碼）或開發語言無標準日志組件的服務。而另外一種方式則是通過日志的 SocketAppender，直接將日志通過網絡寫入遠程的日志服務，如 LogStash，很多標準的日志組件都支持這種方式，如 Java 標準日志輸出如 Log4j，Logback 等。這種方式也比較適合在容器中部署的微服務，不需要額外再部署另外的日志工具。在我們微服務平臺中，日志輸出我們選用了性能較高的 Logback，并選用了與之配套的 LogStash 輸出插件，通過該插件（代理）Logback 可以將日志通過 Socket 直接輸出到 Logstash 服務，而這毋須對代碼做任何改動，僅需要通過簡單的配置文件配置即可方便實現，對調用日志的應用微服務完全透明。
為便于后續的日志查找和 Kibana 中的日志數據展示 我們需要對日志的格式進行規范化，以便將日志中的關鍵信息以鍵值對的方式存入 ElasticSearch，規范化涉及到日志文本的編碼與解碼，分別在應用端和 LogStash 端，LogStash 服務可以通過配置來對消息進行 Mapping 和過濾。
如果日志量比較大，則需要在日志輸出與 LogStash 中間增加消息緩沖，Kafka 是一個高吞吐量的消息系統，Log4j2 有直接輸出到 Kafka 的 Appender。
監控系統是平臺服務治理中的一個重要組成部分，沒有監控的應用系統可以稱作一個裸奔的系統；我們原有的業務平臺已經有了一套傳統的監控系統 Netgain，但更多是對基礎設施的監控，缺乏對應用系統內部狀態的真正監控，比如對微服務和容器的支持，不能很好滿足 UFOS 微服務平臺的需求。
Prometheus 作為從 CNCF 畢業的第二個開源項目（第一個是容器編排項目 Kurbernetes，Prometheus 本來也是源自 Google 對 Kurbernetes 的監控），它能很好地監控服務以及容器，除了能與 Kurbernetes 無縫集成以外，也可以與 Swarm 很好地集成，尤其是配合 Docker Swarm 中的 label 與 global 配置選項使用，可以非常方便實施遠程應用監控代理（exporter）的部署。
由于 Prometheus 是一個開放的監控平臺，因此有大量的官方及第三方的監控代理 Exporter（監控代理可以協助不支持 Prometheus 數據采集接口的第三方服務公開自身的監控數據），在 UFOS 中主要使用了以下監控 / 代理：
Prometheus 提供多種客戶端 API 接口調用庫，如官方提供 Java，Python，Go，第三方提供 C++，PHP 等庫，通過這些庫你可以很方便在你的微服務中植入監控的度量數據（通過微服務 Web 接口，如果是批處理任務，則可以將生成的監控度量數據發送到 PushGateway 服務進行托管），為 Prometheus 服務進程拉取到，這樣我們可以方便實現對業務數據的監控。
監控界面展示使用 Grafana，Grafana 是一個開源的圖表可視化系統，支持多種時序數據庫如 InfluxDB，當然也支持 Prometheus，Grafana 有豐富的圖形展示組件，官方網站也提供大量現成的模板，UFOS 中對 Swarm 節點，微服務，數據庫，告警等資源進行了監控展示。
為保障業務的穩定可用，平臺應保證持續可用，不會無故宕機，即使出現故障也可以快速發現和定位，通過監控機制，能在系統用戶發現之前盡快解決問題，抑或系統能通過設計自動發現故障并進行自動故障轉移，比如通過主備或集群的冗余方式來避免單點的問題，這里我們將針對后者，從系統設計來提升系統高可用性進行簡要介紹。
UFOS 運行平臺基于 Linux 系統，平臺入口是 HTTP 反向代理 Traefik，為實現入口的高可用，我們必須保證 Traefik 的冗余備份。
Traefik 本身支持集群方式的 HA 方式，基于配置的 K/V 存儲，官方推薦的是 Consul。但是由于我們服務平臺是基于 Swarm 集群，Traefik 是以 Swarm 服務方式運行（限制在 Swarm Manager 節點），它可以通過 Swarm Manager 節點讀取到足夠的 Swarm 中運行的服務實例的相關信息。而 Swarm Manger 之間通過 Raft 算法實時交換信息，因此運行多個獨立的 Traefik 實例它們獲的服務實例信息是最新也是對等的，所以我們并不需要按官方指引的使用 K/V 存儲來實現 Traefik 的高可用。
為實現 Traefik 的故障自動轉移，我們對運行 Traefik Replica 實例的 Swarm Manager 節點設計了基于 VIP 的 Linux 集群方案，使用 Pacemaker+Corosync，其中 Corosync 用于檢測節點間通訊是否正常，而 pacemaker 則用于管理集群資源。當檢測到 Linux 集群中的任何一臺節點故障時 VIP 會自動切換到其他的正常節點，入口也自動切換到該節點上運行的 Traefik 上來，保證 HTTP 訪問代理的可用。
所有的微服務都是以 Swarm 服務的方式運行在 Swarm 容器平臺上，微服務的高可用性由 Swarm 提供。Swarm 容器編排系統本身支持高可用，在 UFOS Swarm 集群中配置了三臺 Manager 節點（最多可以承受一臺 Manager 故障），Manager 之間通過 Raft 進行 Leader 的選舉，這種選舉保證了單個節點的異常不影響整個 Swarm 集群的運行。
Swarm 中運行的微服務容器也是高可用的，一是可以通過啟動多個相同微服務實例來實現微服務的高可用，Swarm 內部可以通過 VIP 的方式來實現微服務容器之間的負載均衡與故障的無縫切換（VIP 只會轉發到健康的服務）。即使是單個微服務容器實例，Swarm 仍能保證微服務的高可用性，如因節點故障，導致節點中運行的微服務容器異常，Swarm Manager 可以自動檢測到節點異常，然后把異常節點中的微服務容器，轉移到集群中其他健康的節點上去，并在其他節點重啟微服務應用，這樣仍然可以保證容器中運行的微服務可以被訪問，從而實現微服務的高可用性（容器編排技術可以保證容器的動態發現，即使容器被轉移到其他節點上重啟，從而實現微服務的動態訪問，當然這里可能有個延遲，要實現這點還有一個就是需要保證微服務被設計為無狀態的）。
Oracle Database 采用典范的 RAC 集群，MongoDB 則是基于官方提供的容器鏡像，以容器方式實現了三臺 MongoDB 的 Replica 配置。
Redis 采用主從復制模式，配置了一主二從三個節點，同時配置了相等數目的 Redis Sentinel，這些 Sentinel 能共同合作完成故障發現與判斷，以及故障轉移，并通知應用方，從而實現真正的高可用。
ActiveMQ 采用官方推薦方式，實現了基于 RDBMS 的主從模式，從消息隊列定時從 RDBMS 共享表中檢測主消息隊列的刷新情況，如主消息隊列異常，未能在指定時間內更新，從消息隊列提升自己為主消息隊列，從而實現主從的切換。這里需要注意的是必須保證主從服務節點的系統時間的同步。
文件系統的高可用是通過 NFS 文件系統與底層的存儲來實現。
經過生產環境的實踐，隨著平臺的不斷完善和運維經驗的不斷積累，UFOS 平臺的可用性已從 99.95% 逐步提升到了 99.99%。
該基于容器的微服務架構平臺給我們的研發帶來了以下益處：
經過三年多微服務平臺運營實踐，總結起來該基于容器的微服務架構平臺給我們的研發帶來以下益處：
由于完全基于開源系統，可以實現自主可控
平臺基本對于開發人員來說透明，同時 DevOps 使得運維簡單，有效提升了研發效率，節省了人力資源方面的投入
平臺微服務開發語言選擇更具彈性，現在平臺中已有三種語言開發的微服務，而且平臺還可以根據開發語言的發展進行語言的更迭，也可以根據市場的變化對開發語言進行調整，最大限度保護現有投資，以及最佳化未來投入
實現公司的統一開發服務云平臺，可以無縫整合現存的第三方服務商提供的服務，有效利用平臺在服務治理方面的資源
可以方便整合第三方開源軟件系統為平臺直接使用，為平臺提供服務，有效節省開發人力投入
容器運行環境高度統一，微服務問題可以排除干擾，便于問題分析與排查
該架構平臺運行非常穩定，可用性高，可擴展性強，可以根據業務需要進行動態擴展，可以滿足公司業務的未來長期發展的需要，并且技術架構有一定的前瞻性，有效避免了因平臺架構選型不當導致后續的平臺改造移植造成大量的遷移和重構工作，保護了投資（資源投入，包括人力）。
該平臺架構可以作為中小企業對微服務平臺架構選型的一種參考，當然你可以使用 Kubernetes 替換 Docker Swarm， 畢竟后者成為了小眾產品（如果從入手的簡潔性，Swarm 依然還是具有吸引力的，幾天之類上手），其他子系統的選型也可以作為參考。
關于如何分析基于容器的微服務架構技術選型與設計問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
