原文地址：https://www.infoq.cn/article/AJj3lKQyaKVeA08Bgj9e

背景

為數(shù)以億計(jì)的用戶提供優(yōu)質(zhì)的視頻服務(wù)的愛(ài)奇藝技術(shù)產(chǎn)品團(tuán)隊(duì)，為了適應(yīng)業(yè)務(wù)的快速迭代和創(chuàng)新，并支撐海量的用戶請(qǐng)求，很多團(tuán)隊(duì)都對(duì)各自的業(yè)務(wù)系統(tǒng)自發(fā)地進(jìn)行了微服務(wù)架構(gòu)的改造。

在微服務(wù)化的過(guò)程中，各業(yè)務(wù)團(tuán)隊(duì)根據(jù)自身需要選擇了不同的開(kāi)源框架，如 Apache Dubbo/Spring Cloud 等，此外也存在一些自研性質(zhì)的框架；另外為了滿足對(duì)微服務(wù)應(yīng)用的監(jiān)控等需求，不少團(tuán)隊(duì)還自行維護(hù)了監(jiān)控系統(tǒng)等基礎(chǔ)設(shè)施。

隨著實(shí)踐的深入，一些問(wèn)題逐漸開(kāi)始暴露，這其中包括：

·部分基礎(chǔ)設(shè)施存在重復(fù)建設(shè)，在資源浪費(fèi)的同時(shí)穩(wěn)定性也不易保證；

·由于使用的技術(shù)架構(gòu)和 SDK 不統(tǒng)一，最佳實(shí)踐難以在團(tuán)隊(duì)間快速推廣；

·技術(shù)架構(gòu)不統(tǒng)一導(dǎo)致在東西向流量中大量引入了業(yè)務(wù)自行維護(hù)的網(wǎng)關(guān)，使得鏈路加長(zhǎng)，影響排障效率和響應(yīng)延時(shí)。

為了解決以上問(wèn)題，愛(ài)奇藝中間件團(tuán)隊(duì)充分聽(tīng)取了業(yè)務(wù)在微服務(wù)實(shí)踐中的需求和問(wèn)題，推出了愛(ài)奇藝的微服務(wù)標(biāo)準(zhǔn)架構(gòu)。在標(biāo)準(zhǔn)架構(gòu)的建設(shè)過(guò)程中，我們主要遵循了以下的一些原則：

1.架構(gòu)統(tǒng)一：同一技術(shù)領(lǐng)域往往有多種技術(shù)實(shí)現(xiàn)，但是過(guò)多的技術(shù)框架的采用容易造成維護(hù)成本過(guò)高，缺乏專(zhuān)人支持等問(wèn)題。在微服務(wù)標(biāo)準(zhǔn)架構(gòu)的選型過(guò)程中，我們綜合了各開(kāi)源項(xiàng)目的實(shí)際情況和業(yè)界的主流技術(shù)方案，將各個(gè)領(lǐng)域中的技術(shù)選型進(jìn)行了統(tǒng)一，每個(gè)領(lǐng)域的技術(shù)選型原則上均不超過(guò) 1 種。

2.可擴(kuò)展：微服務(wù)標(biāo)準(zhǔn)架構(gòu)中有不少開(kāi)發(fā) SDK 的選型，為了滿足各個(gè)開(kāi)發(fā)團(tuán)隊(duì)不同的業(yè)務(wù)需求，需要保證各個(gè) SDK 的可擴(kuò)展性，如果開(kāi)源版本無(wú)法滿足內(nèi)部需求的，愛(ài)奇藝中間件團(tuán)隊(duì)都會(huì)維護(hù)統(tǒng)一化的內(nèi)部定制版本。

3.高可用：標(biāo)準(zhǔn)架構(gòu)的建設(shè)目的之一是將各個(gè)團(tuán)隊(duì)維護(hù)的基礎(chǔ)設(shè)施（如注冊(cè)中心、監(jiān)控系統(tǒng)等）逐漸收攏至內(nèi)部的公共平臺(tái)。對(duì)相關(guān)平臺(tái)的技術(shù)架構(gòu) review 及可用性維護(hù)也是我們的重要工作之一，此外我們還建設(shè)了服務(wù)成熟度體系 SMMI，會(huì)定期對(duì)核心系統(tǒng)及基礎(chǔ)服務(wù)進(jìn)行成熟度評(píng)估。

4.技術(shù)演進(jìn)：開(kāi)源軟件均有其生命周期，需要充分考慮各個(gè)軟件的社區(qū)維護(hù)情況，比如在熔斷技術(shù)選型上，我們?cè)跇?biāo)準(zhǔn)架構(gòu)中主推了 Sentinel，而不是目前已經(jīng)停止維護(hù)的 Hystrix。另外標(biāo)準(zhǔn)架構(gòu)也并非一個(gè)一成不變的體系，對(duì)于新技術(shù)的采納，我們也提供了標(biāo)準(zhǔn)化的流程，確保我們的技術(shù)體系能持續(xù)迭代。

5.內(nèi)部開(kāi)源：在標(biāo)準(zhǔn)架構(gòu)的建設(shè)過(guò)程中，在愛(ài)奇藝內(nèi)部開(kāi)展了內(nèi)部開(kāi)源的協(xié)作模式。除了基礎(chǔ)服務(wù)部門(mén)以外，也鼓勵(lì)業(yè)務(wù)團(tuán)隊(duì)參與到這些基礎(chǔ)服務(wù)的維護(hù)工作中來(lái)，共同打造一個(gè)即符合業(yè)務(wù)需求，又有一定業(yè)界領(lǐng)先度的微服務(wù)技術(shù)體系，這樣也進(jìn)一步促進(jìn)了相關(guān)標(biāo)準(zhǔn)架構(gòu)的推廣和完善。

愛(ài)奇藝微服務(wù)標(biāo)準(zhǔn)架構(gòu)

下圖展示了愛(ài)奇藝微服務(wù)標(biāo)準(zhǔn)架構(gòu)的全貌：

標(biāo)準(zhǔn)架構(gòu)主要包括如下主要內(nèi)容：

*統(tǒng)一的微服務(wù)開(kāi)發(fā) SDK：核心開(kāi)發(fā)框架 Dubbo/Spring Cloud；熔斷限流框架 Sentinel 等；

*統(tǒng)一的微服務(wù)基礎(chǔ)設(shè)施，包括：

·注冊(cè)中心：Nacos/consul；

·服務(wù)網(wǎng)關(guān)：基于 kong 進(jìn)行二次開(kāi)發(fā)的網(wǎng)關(guān)平臺(tái)，提供鑒權(quán)、限流等功能；

· 配置中心：基于攜程 Apollo 進(jìn)行二次開(kāi)發(fā)的平臺(tái)

·指標(biāo)監(jiān)控：prometheus 集群托管服務(wù)；

·鏈路監(jiān)控：全鏈路平臺(tái)（基于 skywalking 進(jìn)行定制開(kāi)發(fā)）；

·混沌工程：在 ChaosBlade 基礎(chǔ)上進(jìn)行二次研發(fā)，提供各類(lèi)故障演練功能。

*統(tǒng)一的微服務(wù)平臺(tái)：QDAS（QIYI Distributed Application Service，愛(ài)奇藝分布式應(yīng)用服務(wù)），提供微服務(wù)應(yīng)用生命周期管理、服務(wù)治理、服務(wù)市場(chǎng)等功能。

標(biāo)準(zhǔn)架構(gòu)生態(tài)建設(shè)

以下將從微服務(wù) SDK、注冊(cè)中心、監(jiān)控體系、熔斷限流、API 網(wǎng)關(guān)、微服務(wù)平臺(tái)等幾個(gè)微服務(wù)標(biāo)準(zhǔn)架構(gòu)的核心點(diǎn)做一些展開(kāi)的介紹。

開(kāi)源 SDK 定制

根據(jù)各個(gè)業(yè)務(wù)團(tuán)隊(duì)的需求，愛(ài)奇藝中間件團(tuán)隊(duì)主要對(duì) Dubbo SDK 做了以下幾方面的擴(kuò)展：

1.基礎(chǔ)設(shè)施的適配：包括注冊(cè)中心、監(jiān)控系統(tǒng)、內(nèi)部的容器平臺(tái)等等；

2.可用性增強(qiáng)：包括非健康實(shí)例隔離以及區(qū)域就近路由的機(jī)制；

3.安全性增強(qiáng)：支持了服務(wù)間調(diào)用的認(rèn)證機(jī)制；

4.序列化：增加了對(duì) protobuf 序列化方式的支持。

注冊(cè)中心演進(jìn)

注冊(cè)中心在微服務(wù)應(yīng)用中是最重要的基礎(chǔ)設(shè)施之一，原先在愛(ài)奇藝內(nèi)部，注冊(cè)中心的選型并不統(tǒng)一，之前在線上運(yùn)行的注冊(cè)中心有 ZooKeeper、eureka、consul 等。事實(shí)上，ZooKeeper、eureka 等并不是當(dāng)前業(yè)界中微服務(wù)注冊(cè)中心的最佳選型，以 Zookeeper 為例，其主要缺點(diǎn)包括：

1.無(wú)法橫向擴(kuò)展；

2.作為一個(gè)一致性的系統(tǒng)，在網(wǎng)絡(luò)分區(qū)會(huì)產(chǎn)生不可用。

在調(diào)研了業(yè)界的各個(gè)方案后，我們選用了 Nacos 作為我們下一代的微服務(wù)注冊(cè)中心。右下角是 Nacos 的整體介紹圖，選用 Nacos 的主要原因是：

1.高性能，可以橫向擴(kuò)展；

2.既適用于傳統(tǒng)為服務(wù)架構(gòu)，也能適用于云原生環(huán)境，包括支持與 Istio 控制面對(duì)接；

3.提供了 Nacos-Sync 組件，可與其他注冊(cè)中心進(jìn)行數(shù)據(jù)同步，也使注冊(cè)中心的遷移變得簡(jiǎn)便。

Nacos 高可用部署

在部署 Nacos 服務(wù)時(shí)，我們充分考慮了服務(wù)部署架構(gòu)方面的高可用性。目前我們的 Nacos 服務(wù)是一個(gè)大集群，實(shí)例分布在多個(gè)不同的可用區(qū)中，在每個(gè)可用區(qū)內(nèi)部，我們會(huì)申請(qǐng)不同的 VIP，最終的內(nèi)網(wǎng)域名是綁定在這些 VIP 上。另外其底層所使用的 MySQL 也采用了多機(jī)房部署。這樣的架構(gòu)可以避免單個(gè) Nacos 實(shí)例或者單機(jī)房故障造成整個(gè) Nacos 服務(wù)的不可用。以下是一些可能的故障場(chǎng)景的模擬：

1.單個(gè) Nacos 實(shí)例故障：利用 Load Balancer 集群提供的健康檢查能力自動(dòng)從 VIP 中摘除；

2.某個(gè) VIP 集群故障：利用客戶端重試機(jī)制解決；

3.單個(gè) AZ 故障：利用客戶端重試機(jī)制解決；

4.MySQL 集群故障：MySQL 與注冊(cè)發(fā)現(xiàn)過(guò)程無(wú)關(guān)，不受影響；

5.整個(gè) Nacos 服務(wù)故障：客戶端兜底機(jī)制，如服務(wù)實(shí)例緩存等。

注冊(cè)中心平滑遷移方案

接下來(lái)將簡(jiǎn)單介紹一下如何使用 Nacos-Sync 進(jìn)行注冊(cè)中心的平滑遷移。

1.首先要部署一個(gè) Nacos-Sync 服務(wù)，從舊的注冊(cè)中心向 Nacos 同步數(shù)據(jù)。Nacos-Sync 支持集群化部署，部署多個(gè)實(shí)例時(shí)，其向新注冊(cè)中心的寫(xiě)入時(shí)冪等的，并且它原生支持 Dubbo 的注冊(cè)數(shù)據(jù)格式；

2.檢查數(shù)據(jù)無(wú)誤后，首先升級(jí) Consumer 端，改為從 Nacos 注冊(cè)中心進(jìn)行發(fā)現(xiàn)。這時(shí)的服務(wù)發(fā)現(xiàn)的數(shù)據(jù)均是由 Nacos-Sync 從舊的注冊(cè)中心同步過(guò)來(lái)的；

3.再升級(jí) Provider 端，改為向 Nacos 進(jìn)行服務(wù)注冊(cè)；

4.下線 Nacos-Sync 服務(wù)及舊的注冊(cè)中心，整個(gè)遷移流程就結(jié)束了。

以上方案的主要優(yōu)點(diǎn)包括：

*服務(wù)提供方和消費(fèi)方的升級(jí)完全獨(dú)立，可以自行進(jìn)行；

*遷移涉及的應(yīng)用僅需升級(jí)一次。

監(jiān)控體系建設(shè)

服務(wù)監(jiān)控是所有業(yè)務(wù)團(tuán)隊(duì)都極為關(guān)注的主題。完整的微服務(wù)監(jiān)控體系一般需要有以下 3 個(gè)方面組成：

1.指標(biāo)監(jiān)控：包括 QPS/響應(yīng)延時(shí)/錯(cuò)誤率等黃金指標(biāo)、業(yè)務(wù)的自定義指標(biāo)、JAVA 應(yīng)用的 JVM 指標(biāo)，此外還需要采集和基礎(chǔ)環(huán)境的相關(guān)指標(biāo)，包括 CPU/內(nèi)存利用率等；

2.日志監(jiān)控：如錯(cuò)誤日志的數(shù)量；也可以利用 AI 技術(shù)，對(duì)日志的模式進(jìn)行統(tǒng)計(jì)分析等；

3.鏈路監(jiān)控：由于微服務(wù)調(diào)用關(guān)系的復(fù)雜性，調(diào)用鏈追蹤也是非常必要的，它可以幫助業(yè)務(wù)人員更好地分析應(yīng)用間的依賴(lài)關(guān)系，并能夠監(jiān)控各個(gè)調(diào)用關(guān)系上的核心指標(biāo)。

指標(biāo)監(jiān)控

指標(biāo)監(jiān)控方面，我們內(nèi)部圍繞著 Prometheus 建設(shè)了一套較為完整的監(jiān)控和告警的標(biāo)準(zhǔn)化方案。這里面要解決幾個(gè)問(wèn)題：

首先是指標(biāo)計(jì)算的問(wèn)題，為了降低侵入性，我們?cè)?skywalking agent 的基礎(chǔ)上進(jìn)行了二次開(kāi)發(fā)，可以自動(dòng)攔截 Spring MVC/Dubbo 等主流框架的調(diào)用，統(tǒng)計(jì)其調(diào)用次數(shù)、處理耗時(shí)、是否錯(cuò)誤等等。

其次是指標(biāo)采集的問(wèn)題，Prometheus 是采用拉模式采集指標(biāo)的，對(duì)于微服務(wù)場(chǎng)景一般是利用 Prometheus 的服務(wù)發(fā)現(xiàn)機(jī)制。Prometheus 默認(rèn)集成了 consul、k8s 等服務(wù)發(fā)現(xiàn)方式，不過(guò)并未對(duì) Nacos 注冊(cè)中心直接提供支持，我們?cè)陂_(kāi)源的 Nacos adapter 的基礎(chǔ)上進(jìn)行了改造，使得 Prometheus 能夠從 Nacos 中發(fā)現(xiàn)要采集的應(yīng)用實(shí)例信息。

指標(biāo)查看主要采用了 grafana，我們提供了一套通用化的配置模板，業(yè)務(wù)也可以根據(jù)需要自行擴(kuò)展。

告警方面，我們將告警策略設(shè)置在 Prometheus 中，具體的告警會(huì)由 alert-manager 通過(guò) adapter 發(fā)送給內(nèi)部的監(jiān)控告警平臺(tái)。

監(jiān)控 dashboard 查看、告警策略設(shè)置、訂閱的入口統(tǒng)一設(shè)置在我們內(nèi)部的全鏈路監(jiān)控平臺(tái)上，用戶可以在該平臺(tái)上查看進(jìn)行相應(yīng)的操作。

下圖展示了服務(wù)監(jiān)控界面：

鏈路追蹤

鏈路追蹤的基本原理也和 google 關(guān)于 Dapper 的論文一致，應(yīng)用程序通過(guò)埋點(diǎn)的 agent 產(chǎn)生調(diào)用鏈數(shù)據(jù)，通過(guò)日志采集或者網(wǎng)絡(luò)直接上報(bào)的方式統(tǒng)一匯總至 kafka，通過(guò)我們的實(shí)時(shí)分析程序進(jìn)行分析。分析結(jié)果大致可以分為三類(lèi)，原始的調(diào)用鏈數(shù)據(jù)我們會(huì)使用 ES+HBase 進(jìn)行存儲(chǔ)，調(diào)用關(guān)系上的實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)我們采用時(shí)序數(shù)據(jù)庫(kù) druid 進(jìn)行存儲(chǔ)，拓?fù)潢P(guān)系采用圖數(shù)據(jù)存儲(chǔ)。

鏈路追蹤主要提供了一下功能：

1.調(diào)用依賴(lài)關(guān)系分析：提供了服務(wù)間依賴(lài)及接口間依賴(lài)的多個(gè)層次粒度，支持 MySQL/Redis 等各類(lèi)中間件，為開(kāi)發(fā)人員提供各種上下游依賴(lài)的直觀展示；

2.服務(wù)間調(diào)用關(guān)系指標(biāo)：提供 QPS/響應(yīng)延時(shí)錯(cuò)誤率等核心指標(biāo)監(jiān)控，且能在一個(gè)調(diào)用關(guān)系上同時(shí)提供客戶端及服務(wù)端兩個(gè)視角的監(jiān)控值，便于進(jìn)行問(wèn)題定位；

3.程序異常分析：在調(diào)用鏈數(shù)據(jù)中心記錄異常類(lèi)型及堆棧信息并進(jìn)行分析，支持展示某個(gè)應(yīng)用的程序異常種類(lèi)及每分鐘發(fā)生次數(shù)等；

4.日志關(guān)聯(lián)：將調(diào)用鏈與業(yè)務(wù)日志進(jìn)行關(guān)聯(lián)查詢，便于獲取程序運(yùn)行的詳細(xì)信息。

熔斷限流方案

由于微服務(wù)架構(gòu)的特點(diǎn)，上下游依賴(lài)和網(wǎng)絡(luò)通信都比較多，這些因素都會(huì)對(duì)應(yīng)用本身產(chǎn)生一定的風(fēng)險(xiǎn)，比如上游系統(tǒng)的突發(fā)流量或者熱點(diǎn)參數(shù)；下游系統(tǒng)服務(wù)不可用、延時(shí)增大、錯(cuò)誤率升高等等。如果缺少對(duì)自身系統(tǒng)的保護(hù)，有可能產(chǎn)生雪崩的效應(yīng)。為了應(yīng)對(duì)這些場(chǎng)景，我們主要引入了 Sentinel 框架進(jìn)行解決。Sentinel 的核心原理是用戶可以定義各類(lèi)資源（資源可以是本地的一個(gè)接口，或者遠(yuǎn)程的某個(gè)依賴(lài)），并在資源上設(shè)置各種規(guī)則（比如限流規(guī)則），在訪問(wèn)某個(gè)資源時(shí)，Sentinel 組件會(huì)檢查這些規(guī)則是否滿足，在不滿足的情況下會(huì)拋出特定的異常。用戶可以通過(guò)捕捉這些異常實(shí)現(xiàn)快速失敗或者降級(jí)等業(yè)務(wù)邏輯。Sentinel 還提供了一個(gè)控制臺(tái)，可以用來(lái)管理規(guī)則的參數(shù)設(shè)置以及查看實(shí)時(shí)監(jiān)控等。

為了適應(yīng)愛(ài)奇藝各個(gè)業(yè)務(wù)團(tuán)隊(duì)的需求，我們對(duì) sentinel 框架做了一定的擴(kuò)展，下面的例子即是我們實(shí)現(xiàn)的復(fù)雜參數(shù)限流功能。Sentinel 框架本身就自帶熱點(diǎn)參數(shù)限流的功能，不過(guò)僅支持一些簡(jiǎn)單類(lèi)型的參數(shù)（如 String、int 等）。在有些情況下，限流的場(chǎng)景可能比較復(fù)雜，比如下圖中，可能要根據(jù)第一個(gè)參數(shù)的 id 屬性進(jìn)行限流，這種場(chǎng)景原生的 sentinel 并未提供支持。針對(duì)這種情況，我們提供了一個(gè)抽象的接口，允許用戶通過(guò)自己的實(shí)現(xiàn)從參數(shù)中提取出需要限流的資源。

為了實(shí)現(xiàn)規(guī)則參數(shù)的動(dòng)態(tài)下發(fā)，我們將 sentinel 與內(nèi)部的配置中心進(jìn)行了適配。在 sentinel dashboard 上進(jìn)行的參數(shù)改動(dòng)，最后都會(huì)保存至配置中心，業(yè)務(wù)系統(tǒng)通過(guò)引入配置中心的 SDK，即可實(shí)現(xiàn)在不重啟應(yīng)用的前提下進(jìn)行參數(shù)的動(dòng)態(tài)調(diào)整。

在 QDAS 管理平臺(tái)上，我們還利用 k8s 技術(shù)提供了 sentinel dashboard 的托管功能，省去了各業(yè)務(wù)團(tuán)隊(duì)在這方面的部署維護(hù)成本。

API 網(wǎng)關(guān)

愛(ài)奇藝 API 網(wǎng)關(guān)底層基于開(kāi)源項(xiàng)目 Kong 實(shí)現(xiàn)，旨在為開(kāi)發(fā)者提供穩(wěn)定、便捷、高性能、可擴(kuò)展的服務(wù)入口功能，一站式管理 API 配置和生命周期，對(duì)微服務(wù)治理具有重要意義。

在 API 網(wǎng)關(guān)控制流架構(gòu)設(shè)計(jì)中，微服務(wù)平臺(tái) API 網(wǎng)關(guān)模塊通過(guò)內(nèi)部系統(tǒng)集成及服務(wù)化實(shí)現(xiàn)，為開(kāi)發(fā)者提供全部所需入口配置及管理功能，且無(wú)需代碼侵入、工單申請(qǐng)等人工干涉，實(shí)現(xiàn) API 創(chuàng)建即可用。API 網(wǎng)關(guān)支持認(rèn)證、限流、訪問(wèn)控制等通用功能。

結(jié)構(gòu)如下圖所示：

QDAS

在完善的微服務(wù)體系架構(gòu)中，微服務(wù)治理平臺(tái)也必不可少。QDAS 是一個(gè)以應(yīng)用為中心的一站式平臺(tái)，通過(guò)功能插件的形式，對(duì)微服務(wù)應(yīng)用的開(kāi)發(fā)、部署、運(yùn)維各個(gè)環(huán)節(jié)進(jìn)行全生命周期的支持，同時(shí)兼容 Dubbo/Spring Cloud 傳統(tǒng)微服務(wù)框架和 Istio 服務(wù)網(wǎng)格架構(gòu)。

QDAS 平臺(tái)主要支持的功能包括：

1.應(yīng)用基本信息維護(hù)

2.傳統(tǒng)微服務(wù)治理

(1)實(shí)例列表及與 Nacos 注冊(cè)中心集成的實(shí)例上下線管理；

(2)Grafana 核心指標(biāo)監(jiān)控大盤(pán)；

(3)Sentinel dashboard 托管；

(4)基于 Sentinel 的接口鑒權(quán)和流量配額管理（開(kāi)發(fā)中）；

3.應(yīng)用生命周期管理

支持在各類(lèi)平臺(tái)（容器/虛機(jī)）上的應(yīng)用部署和版本升級(jí)功能

4 服務(wù)市場(chǎng)

接口契約管理：包括基于 Swagger UI 的接口描述查看等。

混沌工程

Netflix 最早系統(tǒng)化地提出了混沌工程的概念，目的是盡早的識(shí)別風(fēng)險(xiǎn)，對(duì)薄弱的地方做針對(duì)性的加強(qiáng)。我們也一直在注重自己的故障演練，借助一些內(nèi)部的工具跟外部開(kāi)源項(xiàng)目，逐步演化出自己的故障注入平臺(tái)——小鹿亂撞。借助平臺(tái)，可以編排自己的演練方案進(jìn)行演練，檢驗(yàn)服務(wù)的健壯性。

目前小鹿亂撞平臺(tái)已經(jīng)支持包括服務(wù)器、容器(docker)、數(shù)據(jù)庫(kù)、中間件、網(wǎng)路設(shè)備、k8s 集群等進(jìn)行故障注入，并可在演練過(guò)程中實(shí)時(shí)展示關(guān)聯(lián)的監(jiān)控、日志以及報(bào)警等，演練結(jié)束后自動(dòng)生成演練報(bào)告。

另外，借助平臺(tái)定時(shí)演練的能力，用戶可以方便的實(shí)現(xiàn)周期性演練的效果。

未來(lái)規(guī)劃

對(duì)于微服務(wù)標(biāo)準(zhǔn)架構(gòu)的未來(lái)規(guī)劃，大概分為以下幾方面的工作：

微服務(wù)技術(shù)趨勢(shì)方面，云原生與 service mesh 已經(jīng)是微服務(wù)技術(shù)演進(jìn)的一個(gè)趨勢(shì)了，如何引入 service mesh 技術(shù)，并向各個(gè)業(yè)務(wù)提供平滑過(guò)渡的解決方案，將會(huì)是我們今后工作的一個(gè)重點(diǎn)。

在服務(wù)治理方面，我們會(huì)進(jìn)一步擴(kuò)展 QDAS 平臺(tái)的功能，以期建成一個(gè)對(duì) service mesh 和傳統(tǒng)微服務(wù)都適用的控制面。

在開(kāi)發(fā)者支持方面，未來(lái)計(jì)劃推出項(xiàng)目腳手架以及在線調(diào)試等服務(wù)，使得開(kāi)發(fā)人員能更方便地進(jìn)行項(xiàng)目開(kāi)發(fā)，以及線上問(wèn)題的排查等。