如何分析基于容器的微服務(wù)架構(gòu)技術(shù)選型與設(shè)計(jì)

如何分析基于容器的微服務(wù)架構(gòu)技術(shù)選型與設(shè)計(jì)，針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。

背景介紹

作為金融企業(yè)，國(guó)投瑞銀基金多年以來(lái) IT 工作主要還是以運(yùn)維為主，主要業(yè)務(wù)系統(tǒng)基本采用外購(gòu)模式，但隨著業(yè)務(wù)的不斷發(fā)展，業(yè)務(wù)部門(mén)個(gè)性化需求越積越多，外購(gòu)與外包已經(jīng)不能很好滿足業(yè)務(wù)員部門(mén)的需要了。2016 年底公司著手開(kāi)發(fā)團(tuán)隊(duì)的組建工作，同時(shí)對(duì)公司的業(yè)務(wù)開(kāi)發(fā)平臺(tái)進(jìn)行架構(gòu)選型與設(shè)計(jì)，以求統(tǒng)一開(kāi)發(fā)平臺(tái)，提升研發(fā)效率，從而加快業(yè)務(wù)部門(mén)的業(yè)務(wù)需求處理效率。

下面我們將就這兩年在平臺(tái)架構(gòu)選型、平臺(tái)架構(gòu)設(shè)計(jì)、平臺(tái)及相關(guān)子系統(tǒng)的逐步完善背后的一些經(jīng)驗(yàn)進(jìn)行分享。

適用對(duì)象

該架構(gòu)全部基于開(kāi)源平臺(tái)，經(jīng)過(guò)三年多的生產(chǎn)上線實(shí)踐，平臺(tái)運(yùn)行平穩(wěn)，可擴(kuò)展性強(qiáng)，可用性高，可以很好滿足公司對(duì)于金融業(yè)務(wù)不斷發(fā)展的需要，這對(duì)類(lèi)似的中小型企業(yè)的業(yè)務(wù)架構(gòu)選型也具有一定的參考意義。

注：UFOS：國(guó)投瑞銀基金運(yùn)營(yíng)系統(tǒng)

架構(gòu)設(shè)計(jì)與選型

架構(gòu)設(shè)計(jì)考量因素

在初期平臺(tái)架構(gòu)設(shè)計(jì)與選型時(shí)，我們根據(jù)現(xiàn)有業(yè)務(wù)系統(tǒng)的需求，梳理出了技術(shù)架構(gòu)選型需要考量關(guān)鍵因素：

1. 架構(gòu)平臺(tái)的前瞻性或先進(jìn)性，符合當(dāng)前潮流與未來(lái)發(fā)展趨勢(shì)，有較好的生態(tài)鏈和較強(qiáng)的生命力，不能因?yàn)槠脚_(tái)架構(gòu)選型不當(dāng)，導(dǎo)致未來(lái)平臺(tái)重新架構(gòu)，造成大量的遷移和重構(gòu)工作，需保障平臺(tái)架構(gòu)能在一段時(shí)間內(nèi)保持技術(shù)領(lǐng)先。

   這里有兩點(diǎn)注意，一是對(duì)技術(shù)成熟度的考量，是否采用有風(fēng)險(xiǎn)的前沿技術(shù)以及擁抱這種技術(shù)帶來(lái)的風(fēng)險(xiǎn)，這一點(diǎn)類(lèi)似于金融投資中收益與風(fēng)險(xiǎn)的關(guān)系，我們需要在系統(tǒng)的先進(jìn)性與系統(tǒng)的穩(wěn)定性之間進(jìn)行平衡；二是采用前沿技術(shù)可能會(huì)面對(duì)更多的困難，如國(guó)內(nèi)可能缺乏相關(guān)資料，或難以找到可以參考的成功案例，很多時(shí)候只能通過(guò)官方和論壇獲取相關(guān)技術(shù)信息，會(huì)對(duì)架構(gòu)按時(shí)交付帶來(lái)風(fēng)險(xiǎn)。

2. 平臺(tái)的可擴(kuò)展性

   能滿足基金行業(yè)業(yè)務(wù)不斷的發(fā)展與創(chuàng)新的需求，盡量能做到平臺(tái)的橫向平滑擴(kuò)展，滿足以上特性其實(shí)就決定了架構(gòu)的分布式特性，當(dāng)然我們更希望它是云原生的架構(gòu)

3. 系統(tǒng)的可靠性和可用性

   作為金融業(yè)務(wù)系統(tǒng)平臺(tái)，需保證業(yè)務(wù)系統(tǒng)連續(xù)不間斷運(yùn)行，保證平臺(tái)的高可用。采用集群或平臺(tái)自動(dòng)恢復(fù)功能，確保平臺(tái)局部出錯(cuò)也不影響系統(tǒng)整體的運(yùn)行；這里有兩個(gè)層面，一是業(yè)務(wù)系統(tǒng)中的功能組件能相互隔離，其中一個(gè)組件的不可用不能影響到系統(tǒng)的其他部分；二是平臺(tái)基礎(chǔ)系統(tǒng)采用集群架構(gòu)，有自動(dòng)恢復(fù)功能，確保即使系統(tǒng)中有節(jié)點(diǎn)出錯(cuò)，也可在很短時(shí)間內(nèi)完成出錯(cuò)節(jié)點(diǎn)中服務(wù)的切換與恢復(fù)

4. 開(kāi)銷(xiāo)

   不同的架構(gòu) / 技術(shù)選擇有著不同的開(kāi)發(fā)成本，包括技術(shù)框架，平臺(tái)的學(xué)習(xí)成本，我們期望平臺(tái)能支持異構(gòu)的技術(shù)，使得開(kāi)發(fā)人員可以采用比較適合的技術(shù)棧來(lái)快速實(shí)現(xiàn)業(yè)務(wù)功能的開(kāi)發(fā)

5. 開(kāi)發(fā)運(yùn)維一體化思想（ DevOps ），在設(shè)計(jì)時(shí)考慮運(yùn)維，盡量減少后期運(yùn)維操作的復(fù)雜度，減輕后期業(yè)務(wù)系統(tǒng)運(yùn)維的負(fù)擔(dān)。

6. 讓開(kāi)發(fā)人員更多專(zhuān)注在業(yè)務(wù)功能需求開(kāi)發(fā)，其它非功能需求如負(fù)載均衡、高可用等盡量由平臺(tái)提供，做到對(duì)開(kāi)發(fā)人員透明，以提升開(kāi)發(fā)效率。

當(dāng)公司規(guī)模不大，實(shí)力不足以自己實(shí)現(xiàn)部分或全部架構(gòu)，選擇現(xiàn)成的“輪子”來(lái)組裝自己的架構(gòu)就成了一種自然的選擇。在選擇上可能會(huì)更多考慮如何使用更“標(biāo)準(zhǔn)”的“輪子”來(lái)滿足自己業(yè)務(wù)的需求，以便于今后業(yè)務(wù)的升級(jí)和擴(kuò)展。

要實(shí)現(xiàn)上述平臺(tái)的擴(kuò)展性和高可用性，一般都離不開(kāi)分布式架構(gòu)，而分布式架構(gòu)一般離不開(kāi)服務(wù)來(lái)承載 。

基于服務(wù)架構(gòu)演進(jìn)

基于服務(wù)的架構(gòu)設(shè)計(jì)早已有之，比如基于 RPC 的服務(wù)調(diào)用，最早可追溯到 CORBA，以及現(xiàn)在還有很多金融公司在交易系統(tǒng)中使用的 BEA 早期的框架 Tuxedo（主要編程語(yǔ)言為 C/C++）。后來(lái)者有 Facebook 的 Thrift，Google Protocolbuf 框架 /grpc，阿里的 Dubbo 框架等等。這些框架支持消息的二進(jìn)制編碼（序列化與反序列化），效率高，因此成了對(duì)網(wǎng)絡(luò)傳輸，并發(fā)處理要求高的應(yīng)用如 App 應(yīng)用，游戲，交易軟件等的首選。

后來(lái)隨著 HTTP 協(xié)議的廣泛應(yīng)用，發(fā)展衍生出面向服務(wù)的架構(gòu)（SOA）的架構(gòu)設(shè)計(jì)，該架構(gòu)一般都應(yīng)用在比較復(fù)雜，大型項(xiàng)目中，為了異構(gòu)系統(tǒng)中的功能復(fù)用，或系統(tǒng)性能的考量將功能模塊獨(dú)立出來(lái)成為服務(wù)，服務(wù)可以分布式部署，服務(wù)之間通過(guò)標(biāo)準(zhǔn)的軟件接口方式在網(wǎng)絡(luò)中相互調(diào)用；為了統(tǒng)一服務(wù)調(diào)用標(biāo)準(zhǔn)，SOA 往往還引入了數(shù)據(jù)總線概念，服務(wù)可以通過(guò)數(shù)據(jù)總線進(jìn)行服務(wù)注冊(cè)，服務(wù)的查找與調(diào)度。

SOA 架構(gòu)中的服務(wù)之間是松耦合的，服務(wù)的顆粒度相對(duì)比較粗，而近些年出現(xiàn)的微服務(wù)，則可以看作是對(duì) SOA 服務(wù)的一種精簡(jiǎn)，細(xì)化，或者說(shuō)是 SOA 服務(wù)的輕量版。

微服務(wù)

在談及微服務(wù)的時(shí)候，大都會(huì)對(duì)應(yīng)到單體應(yīng)用，以示鮮明對(duì)比；單體應(yīng)用其實(shí)就是一個(gè)服務(wù)中包含了太多種功能的應(yīng)用，它跟面向?qū)ο蟮脑O(shè)計(jì)里的單體類(lèi)（包含太多功能實(shí)現(xiàn)的類(lèi)）的提法頗有些類(lèi)似，英文單詞中有一個(gè)專(zhuān)有名詞 monolithic 來(lái)描述二者：

如果你再仔細(xì)對(duì)照微服務(wù)和類(lèi)，你會(huì)發(fā)現(xiàn)兩者有諸多相似之處，比如微服務(wù)和類(lèi)在設(shè)計(jì)原則上也是一致的，也就是高內(nèi)聚 / 封裝與松耦合，高內(nèi)聚也就是只負(fù)責(zé)一項(xiàng)任務(wù)，也就是單一職責(zé)原則，而松耦合則是指模塊之間的接口盡量簡(jiǎn)單，減少耦合度，這樣也使得開(kāi)發(fā)，獨(dú)立部署和升級(jí)微服務(wù)更加容易。

HTTP 反向代理 / 服務(wù)網(wǎng)關(guān)

微服務(wù)除了內(nèi)部相互之間調(diào)用和通信之外，最終要以某種方式暴露出去，才能讓外界系統(tǒng)（例如 Web 應(yīng)用、移動(dòng)應(yīng)用等）訪問(wèn)到，這就涉及服務(wù)的前端路由，它是連接內(nèi)部微服務(wù)和外部應(yīng)用系統(tǒng)的一個(gè)通道。

HaProxy 與 Ngix 等工具也可以實(shí)現(xiàn) HTTP 反向代理，但基于以下特性，開(kāi)源的 HTTP 反向代理與負(fù)載均衡工具 Traefik 成為我們的最終選擇：

1. Traefik 更適合需要服務(wù)發(fā)現(xiàn)和服務(wù)注冊(cè)的應(yīng)用場(chǎng)景，它 支持多種后臺(tái)應(yīng)用自動(dòng)發(fā)現(xiàn)，如 Docker，Swarm，Kubernetes，Consul 等，它還可以動(dòng)態(tài)監(jiān)測(cè)后臺(tái)服務(wù)的變動(dòng)以自動(dòng)實(shí)時(shí)更新自己的配置。

2. 支持限流與自動(dòng)熔斷功能。

3. 支持配置熱更新。

可以說(shuō) Traefik 非常適合容器化的微服務(wù)，采用 Traefik 可以帶來(lái)以下好處：

1. 服務(wù)反向路由，Traefik 將外部請(qǐng)求反向路由到內(nèi)部具體的微服務(wù)，這樣雖然系統(tǒng)平臺(tái)內(nèi)部是復(fù)雜的分布式微服務(wù)架構(gòu)，但是外部系統(tǒng)從代理上看到的就像是一個(gè)統(tǒng)一的完整服務(wù)，代理屏蔽了后臺(tái)服務(wù)的復(fù)雜性（類(lèi)似 Facade 模式），同時(shí)也可以屏蔽后臺(tái)服務(wù)的升級(jí)和變化。

2. 便于安全控制，服務(wù)通過(guò)代理統(tǒng)一訪問(wèn)后端的微服務(wù)，而代理訪問(wèn)微服務(wù)是通過(guò)容器內(nèi)部網(wǎng)絡(luò)進(jìn)行，也就是微服務(wù)都可以不用暴露端口到容器外端，外部應(yīng)用也就不能直接訪問(wèn)容器里邊的微服務(wù)了，而必須通過(guò) Traefik 代理。代理有微服務(wù)的注冊(cè)信息，它可以根據(jù)微服務(wù)名正確路由到相應(yīng)的 IP/ 端口的微服務(wù)容器。這樣我們的安全策略就只需要集中在 Traefik 代理端控制即可。

3. 提供多種格式度量數(shù)據(jù)，比如可以提供我們采用的 Prometheus 監(jiān)控?cái)?shù)據(jù)格式，提供訪問(wèn)量，調(diào)用延遲，錯(cuò)誤計(jì)數(shù)等數(shù)據(jù)，為后端的性能優(yōu)化或者擴(kuò)容提供數(shù)據(jù)支持。

在我們的架構(gòu)選型中，我們選擇了流行的開(kāi)源框架 ELK 棧；日志寫(xiě)入遠(yuǎn)端的 Elasticsearch，通?？梢圆捎脙煞N方式，一種方式是通過(guò)日志代理，如 Elasticsearch 提供的高效的 Beats 工具，可以將 Beats 與業(yè)務(wù)服務(wù)部署在一起，這適合第三方服務(wù)（沒(méi)有源碼）或開(kāi)發(fā)語(yǔ)言無(wú)標(biāo)準(zhǔn)日志組件的服務(wù)。而另外一種方式則是通過(guò)日志的 SocketAppender，直接將日志通過(guò)網(wǎng)絡(luò)寫(xiě)入遠(yuǎn)程的日志服務(wù)，如 LogStash，很多標(biāo)準(zhǔn)的日志組件都支持這種方式，如 Java 標(biāo)準(zhǔn)日志輸出如 Log4j，Logback 等。這種方式也比較適合在容器中部署的微服務(wù)，不需要額外再部署另外的日志工具。在我們微服務(wù)平臺(tái)中，日志輸出我們選用了性能較高的 Logback，并選用了與之配套的 LogStash 輸出插件，通過(guò)該插件（代理）Logback 可以將日志通過(guò) Socket 直接輸出到 Logstash 服務(wù)，而這毋須對(duì)代碼做任何改動(dòng)，僅需要通過(guò)簡(jiǎn)單的配置文件配置即可方便實(shí)現(xiàn)，對(duì)調(diào)用日志的應(yīng)用微服務(wù)完全透明。

為便于后續(xù)的日志查找和 Kibana 中的日志數(shù)據(jù)展示 我們需要對(duì)日志的格式進(jìn)行規(guī)范化，以便將日志中的關(guān)鍵信息以鍵值對(duì)的方式存入 ElasticSearch，規(guī)范化涉及到日志文本的編碼與解碼，分別在應(yīng)用端和 LogStash 端，LogStash 服務(wù)可以通過(guò)配置來(lái)對(duì)消息進(jìn)行 Mapping 和過(guò)濾。

如果日志量比較大，則需要在日志輸出與 LogStash 中間增加消息緩沖，Kafka 是一個(gè)高吞吐量的消息系統(tǒng)，Log4j2 有直接輸出到 Kafka 的 Appender。

監(jiān)控子系統(tǒng)

監(jiān)控系統(tǒng)是平臺(tái)服務(wù)治理中的一個(gè)重要組成部分，沒(méi)有監(jiān)控的應(yīng)用系統(tǒng)可以稱(chēng)作一個(gè)裸奔的系統(tǒng)；我們?cè)械臉I(yè)務(wù)平臺(tái)已經(jīng)有了一套傳統(tǒng)的監(jiān)控系統(tǒng) Netgain，但更多是對(duì)基礎(chǔ)設(shè)施的監(jiān)控，缺乏對(duì)應(yīng)用系統(tǒng)內(nèi)部狀態(tài)的真正監(jiān)控，比如對(duì)微服務(wù)和容器的支持，不能很好滿足 UFOS 微服務(wù)平臺(tái)的需求。

Prometheus 作為從 CNCF 畢業(yè)的第二個(gè)開(kāi)源項(xiàng)目（第一個(gè)是容器編排項(xiàng)目 Kurbernetes，Prometheus 本來(lái)也是源自 Google 對(duì) Kurbernetes 的監(jiān)控），它能很好地監(jiān)控服務(wù)以及容器，除了能與 Kurbernetes 無(wú)縫集成以外，也可以與 Swarm 很好地集成，尤其是配合 Docker Swarm 中的 label 與 global 配置選項(xiàng)使用，可以非常方便實(shí)施遠(yuǎn)程應(yīng)用監(jiān)控代理（exporter）的部署。

由于 Prometheus 是一個(gè)開(kāi)放的監(jiān)控平臺(tái)，因此有大量的官方及第三方的監(jiān)控代理 Exporter（監(jiān)控代理可以協(xié)助不支持 Prometheus 數(shù)據(jù)采集接口的第三方服務(wù)公開(kāi)自身的監(jiān)控?cái)?shù)據(jù)），在 UFOS 中主要使用了以下監(jiān)控 / 代理：

Prometheus 提供多種客戶端 API 接口調(diào)用庫(kù)，如官方提供 Java，Python，Go，第三方提供 C++，PHP 等庫(kù)，通過(guò)這些庫(kù)你可以很方便在你的微服務(wù)中植入監(jiān)控的度量數(shù)據(jù)（通過(guò)微服務(wù) Web 接口，如果是批處理任務(wù)，則可以將生成的監(jiān)控度量數(shù)據(jù)發(fā)送到 PushGateway 服務(wù)進(jìn)行托管），為 Prometheus 服務(wù)進(jìn)程拉取到，這樣我們可以方便實(shí)現(xiàn)對(duì)業(yè)務(wù)數(shù)據(jù)的監(jiān)控。

監(jiān)控界面展示使用 Grafana，Grafana 是一個(gè)開(kāi)源的圖表可視化系統(tǒng)，支持多種時(shí)序數(shù)據(jù)庫(kù)如 InfluxDB，當(dāng)然也支持 Prometheus，Grafana 有豐富的圖形展示組件，官方網(wǎng)站也提供大量現(xiàn)成的模板，UFOS 中對(duì) Swarm 節(jié)點(diǎn)，微服務(wù)，數(shù)據(jù)庫(kù)，告警等資源進(jìn)行了監(jiān)控展示。

高可用設(shè)計(jì)

為保障業(yè)務(wù)的穩(wěn)定可用，平臺(tái)應(yīng)保證持續(xù)可用，不會(huì)無(wú)故宕機(jī)，即使出現(xiàn)故障也可以快速發(fā)現(xiàn)和定位，通過(guò)監(jiān)控機(jī)制，能在系統(tǒng)用戶發(fā)現(xiàn)之前盡快解決問(wèn)題，抑或系統(tǒng)能通過(guò)設(shè)計(jì)自動(dòng)發(fā)現(xiàn)故障并進(jìn)行自動(dòng)故障轉(zhuǎn)移，比如通過(guò)主備或集群的冗余方式來(lái)避免單點(diǎn)的問(wèn)題，這里我們將針對(duì)后者，從系統(tǒng)設(shè)計(jì)來(lái)提升系統(tǒng)高可用性進(jìn)行簡(jiǎn)要介紹。

接入層

UFOS 運(yùn)行平臺(tái)基于 Linux 系統(tǒng)，平臺(tái)入口是 HTTP 反向代理 Traefik，為實(shí)現(xiàn)入口的高可用，我們必須保證 Traefik 的冗余備份。

Traefik 本身支持集群方式的 HA 方式，基于配置的 K/V 存儲(chǔ)，官方推薦的是 Consul。但是由于我們服務(wù)平臺(tái)是基于 Swarm 集群，Traefik 是以 Swarm 服務(wù)方式運(yùn)行（限制在 Swarm Manager 節(jié)點(diǎn)），它可以通過(guò) Swarm Manager 節(jié)點(diǎn)讀取到足夠的 Swarm 中運(yùn)行的服務(wù)實(shí)例的相關(guān)信息。而 Swarm Manger 之間通過(guò) Raft 算法實(shí)時(shí)交換信息，因此運(yùn)行多個(gè)獨(dú)立的 Traefik 實(shí)例它們獲的服務(wù)實(shí)例信息是最新也是對(duì)等的，所以我們并不需要按官方指引的使用 K/V 存儲(chǔ)來(lái)實(shí)現(xiàn) Traefik 的高可用。

為實(shí)現(xiàn) Traefik 的故障自動(dòng)轉(zhuǎn)移，我們對(duì)運(yùn)行 Traefik Replica 實(shí)例的 Swarm Manager 節(jié)點(diǎn)設(shè)計(jì)了基于 VIP 的 Linux 集群方案，使用 Pacemaker+Corosync，其中 Corosync 用于檢測(cè)節(jié)點(diǎn)間通訊是否正常，而 pacemaker 則用于管理集群資源。當(dāng)檢測(cè)到 Linux 集群中的任何一臺(tái)節(jié)點(diǎn)故障時(shí) VIP 會(huì)自動(dòng)切換到其他的正常節(jié)點(diǎn)，入口也自動(dòng)切換到該節(jié)點(diǎn)上運(yùn)行的 Traefik 上來(lái)，保證 HTTP 訪問(wèn)代理的可用。

應(yīng)用服務(wù)層

所有的微服務(wù)都是以 Swarm 服務(wù)的方式運(yùn)行在 Swarm 容器平臺(tái)上，微服務(wù)的高可用性由 Swarm 提供。Swarm 容器編排系統(tǒng)本身支持高可用，在 UFOS Swarm 集群中配置了三臺(tái) Manager 節(jié)點(diǎn)（最多可以承受一臺(tái) Manager 故障），Manager 之間通過(guò) Raft 進(jìn)行 Leader 的選舉，這種選舉保證了單個(gè)節(jié)點(diǎn)的異常不影響整個(gè) Swarm 集群的運(yùn)行。

Swarm 中運(yùn)行的微服務(wù)容器也是高可用的，一是可以通過(guò)啟動(dòng)多個(gè)相同微服務(wù)實(shí)例來(lái)實(shí)現(xiàn)微服務(wù)的高可用，Swarm 內(nèi)部可以通過(guò) VIP 的方式來(lái)實(shí)現(xiàn)微服務(wù)容器之間的負(fù)載均衡與故障的無(wú)縫切換（VIP 只會(huì)轉(zhuǎn)發(fā)到健康的服務(wù)）。即使是單個(gè)微服務(wù)容器實(shí)例，Swarm 仍能保證微服務(wù)的高可用性，如因節(jié)點(diǎn)故障，導(dǎo)致節(jié)點(diǎn)中運(yùn)行的微服務(wù)容器異常，Swarm Manager 可以自動(dòng)檢測(cè)到節(jié)點(diǎn)異常，然后把異常節(jié)點(diǎn)中的微服務(wù)容器，轉(zhuǎn)移到集群中其他健康的節(jié)點(diǎn)上去，并在其他節(jié)點(diǎn)重啟微服務(wù)應(yīng)用，這樣仍然可以保證容器中運(yùn)行的微服務(wù)可以被訪問(wèn)，從而實(shí)現(xiàn)微服務(wù)的高可用性（容器編排技術(shù)可以保證容器的動(dòng)態(tài)發(fā)現(xiàn)，即使容器被轉(zhuǎn)移到其他節(jié)點(diǎn)上重啟，從而實(shí)現(xiàn)微服務(wù)的動(dòng)態(tài)訪問(wèn)，當(dāng)然這里可能有個(gè)延遲，要實(shí)現(xiàn)這點(diǎn)還有一個(gè)就是需要保證微服務(wù)被設(shè)計(jì)為無(wú)狀態(tài)的）。

數(shù)據(jù)層

Oracle Database 采用典范的 RAC 集群，MongoDB 則是基于官方提供的容器鏡像，以容器方式實(shí)現(xiàn)了三臺(tái) MongoDB 的 Replica 配置。

Redis 采用主從復(fù)制模式，配置了一主二從三個(gè)節(jié)點(diǎn)，同時(shí)配置了相等數(shù)目的 Redis Sentinel，這些 Sentinel 能共同合作完成故障發(fā)現(xiàn)與判斷，以及故障轉(zhuǎn)移，并通知應(yīng)用方，從而實(shí)現(xiàn)真正的高可用。

ActiveMQ 采用官方推薦方式，實(shí)現(xiàn)了基于 RDBMS 的主從模式，從消息隊(duì)列定時(shí)從 RDBMS 共享表中檢測(cè)主消息隊(duì)列的刷新情況，如主消息隊(duì)列異常，未能在指定時(shí)間內(nèi)更新，從消息隊(duì)列提升自己為主消息隊(duì)列，從而實(shí)現(xiàn)主從的切換。這里需要注意的是必須保證主從服務(wù)節(jié)點(diǎn)的系統(tǒng)時(shí)間的同步。

文件系統(tǒng)的高可用是通過(guò) NFS 文件系統(tǒng)與底層的存儲(chǔ)來(lái)實(shí)現(xiàn)。

經(jīng)過(guò)生產(chǎn)環(huán)境的實(shí)踐，隨著平臺(tái)的不斷完善和運(yùn)維經(jīng)驗(yàn)的不斷積累，UFOS 平臺(tái)的可用性已從 99.95% 逐步提升到了 99.99%。

該基于容器的微服務(wù)架構(gòu)平臺(tái)給我們的研發(fā)帶來(lái)了以下益處：

經(jīng)過(guò)三年多微服務(wù)平臺(tái)運(yùn)營(yíng)實(shí)踐，總結(jié)起來(lái)該基于容器的微服務(wù)架構(gòu)平臺(tái)給我們的研發(fā)帶來(lái)以下益處：

1. 由于完全基于開(kāi)源系統(tǒng)，可以實(shí)現(xiàn)自主可控

2. 平臺(tái)基本對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)透明，同時(shí) DevOps 使得運(yùn)維簡(jiǎn)單，有效提升了研發(fā)效率，節(jié)省了人力資源方面的投入

3. 平臺(tái)微服務(wù)開(kāi)發(fā)語(yǔ)言選擇更具彈性，現(xiàn)在平臺(tái)中已有三種語(yǔ)言開(kāi)發(fā)的微服務(wù)，而且平臺(tái)還可以根據(jù)開(kāi)發(fā)語(yǔ)言的發(fā)展進(jìn)行語(yǔ)言的更迭，也可以根據(jù)市場(chǎng)的變化對(duì)開(kāi)發(fā)語(yǔ)言進(jìn)行調(diào)整，最大限度保護(hù)現(xiàn)有投資，以及最佳化未來(lái)投入

4. 實(shí)現(xiàn)公司的統(tǒng)一開(kāi)發(fā)服務(wù)云平臺(tái)，可以無(wú)縫整合現(xiàn)存的第三方服務(wù)商提供的服務(wù)，有效利用平臺(tái)在服務(wù)治理方面的資源

5. 可以方便整合第三方開(kāi)源軟件系統(tǒng)為平臺(tái)直接使用，為平臺(tái)提供服務(wù)，有效節(jié)省開(kāi)發(fā)人力投入

6. 容器運(yùn)行環(huán)境高度統(tǒng)一，微服務(wù)問(wèn)題可以排除干擾，便于問(wèn)題分析與排查

7. 該架構(gòu)平臺(tái)運(yùn)行非常穩(wěn)定，可用性高，可擴(kuò)展性強(qiáng)，可以根據(jù)業(yè)務(wù)需要進(jìn)行動(dòng)態(tài)擴(kuò)展，可以滿足公司業(yè)務(wù)的未來(lái)長(zhǎng)期發(fā)展的需要，并且技術(shù)架構(gòu)有一定的前瞻性，有效避免了因平臺(tái)架構(gòu)選型不當(dāng)導(dǎo)致后續(xù)的平臺(tái)改造移植造成大量的遷移和重構(gòu)工作，保護(hù)了投資（資源投入，包括人力）。

該平臺(tái)架構(gòu)可以作為中小企業(yè)對(duì)微服務(wù)平臺(tái)架構(gòu)選型的一種參考，當(dāng)然你可以使用 Kubernetes 替換 Docker Swarm， 畢竟后者成為了小眾產(chǎn)品（如果從入手的簡(jiǎn)潔性，Swarm 依然還是具有吸引力的，幾天之類(lèi)上手），其他子系統(tǒng)的選型也可以作為參考。

關(guān)于如何分析基于容器的微服務(wù)架構(gòu)技術(shù)選型與設(shè)計(jì)問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開(kāi)，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。