Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 十二項架構設計原則
Similaire à 十二項架構設計原則 (20)
Plus de Philip Zheng
Plus de Philip Zheng (20)
十二項架構設計原則
- 2. About Me 開源技術愛好者，共同發起 Docker.Taipei社群，獲選微軟MVP，並 翻譯審閱多本容器技術書籍。 台北富邦銀行雲端系統部架構師 國泰金控技術架構師 momo購物網架構師等
- 3. Scalability Rules: Principles for Scaling Web Sites ● 準則 1 - 不要過度設計解決方案 ● 準則 2 - 將設計擴展到解決方案（DID 過程） ● 準則 3 - 將解決方案簡化三倍 ● 準則 4 - 減少 DNS 查找 ● 準則 5 - 盡可能減少對象 ● 準則 6 - 使用同構網絡 ● 準則 7 - 克隆或複制事物的設計（X 軸） ● 準則 8 - 設計拆分不同的東西（Y 軸） ● 準則 9 - 拆分相似事物的設計（Z 軸） ● 準則 10 - 設計您的解決方案以橫向擴展， 而不僅僅是向上擴展 ● 準則 11 - 使用商品系統（金魚不是純種） ● 準則 12 - 擴展您的託管解決方案 ● 準則 13 - 利用雲的設計 ● 準則 14 - 適當使用資料庫 ● 準則 15 - 防火牆，防火牆無處不在！ ● 準則 16 - 積極使用日誌文件 ● 準則 17 - 不要檢查你的工作 ● 準則 18 - 停止重定向流量 ● 準則 19 - 放鬆時間約束 ● 準則 20 - 利用內容交付網絡 ● 準則 21 - 使用Expires標題 ● 準則 22 - 緩存 Ajax 調用 ● 準則 23 - 利用頁面緩存 ● 準則 24 - 利用應用程序緩存 ● 準則 25 - 利用對象暫存 ● 準則 26 - 將對象暫存放在自己的“層”上 ● 準則 27 - 積極學習 ● 準則 28 - 不要依賴 QA 來發現錯誤 ● 準則 29 - 不為回滾而設計就是為失敗而設計 ● 準則 30 - 從事務處理中刪除商業智能 ● 準則 31 - 注意代價高昂的關係 ● 準則 32 - 使用正確類型的數據庫鎖 ● 準則 33 - 使用多階段提交傳遞 ● 準則 34 - 盡量不要使用Select for Update ● 準則 35 - 不要選擇一切 ● 準則 36 - 使用故障隔離“泳道”進行設計 ● 準則 37 - 永遠不要相信單點故障 ● 準則 38 - 避免將系統串聯起來 ● 準則 39 - 確保您可以連接和關閉功能 ● 準則 40 - 爭取無國籍 剩下自己看吧～ 總共50項可擴展準則
- 4. 50項 → 12 項架構設計原則 篩選重點，並以三維構面Scale Cube來分類拆分，其中XYZ軸 分別表示： ◼ X軸，水平擴展，即將服務 和數據複製多份 ◼ Y軸，根據功能或業務來對 應用進行拆分(比如微服務) ◼ Z軸，依據服務或是數據進 行Sharding分區 出處：https://akfpartners.com/growth-blog/scale-cube
- 5. 原則一：避免過度設計 說明(What)： 在系統設計過程中要警惕複雜的解決方案。 場景(When)： 適用各種資訊專案，特別是大型系統或是複雜系統 的設計過程階段。 方法(How)： 透過測試同仁是否能夠輕易理解架構設計方案，來 驗證是否存在過度設計。 原因(Why)： 複雜的解決方案除了實踐成本過高，且長期的維運 費用高昂。過度設計的系統限制了可擴展性，簡單 的系統易於維護、方便擴展且成本低。 要就幹大事， 響應式+非同步 +微服務架構
- 6. 實際案例 綠界資訊服務設計已朝向微服務架構來發展 梁維誠表示，目前已經完成應用程式的切分，將大服務拆分成幾 個小功能，再把每個功能API化，彼此透過API呼叫。每個微服務 都有對應自己的資料庫，但放在數套資料庫主機上，每支微服務 程式則是放在VM上。但經過實際測試，他們發現將服務拆分後， 再透過網路呼叫API，會產生效能的耗損，比如呼叫一次API，可 能會有100～200毫秒的延遲，多呼叫幾支就需要近1秒，這樣反 應時間太慢。 為了解決這個難題，資訊團隊採取方式是將分散在不同VM的微服 務，全部集中到一臺大VM機器上，當需要呼叫API時，只需要呼 叫本機的API，不需要透過網路，減少網路延遲的情況。他也提到 說，當需部署更多臺VM主機時，只需複製VM即可，也能降低管 理上的成本。 Istio 1.5部署，回歸單體 “過早的優化複雜性是萬惡之源，或者：我如何學 會停止擔心並熱愛單體應用” 這是 istiod 長達 21 頁設計文檔的開篇引用語，原 文出自 Donald Knuth 1974 年在 ACM Journal 上 發表的文章《Structured Programming with go to Statements》
- 7. 原則二：服務X軸擴展 說明(What)： 通常稱為橫向擴展，透過複製相同服務來分攤大量交易的運算負載。 場景(When)： 當執行服務的應用伺服器成為瓶頸，CPU或Memory使用量高。 方法(How)： ◼ 使用VM或容器，來建立足夠支撐負載的大量副本，並保留30% 餘裕資源。 ◼ 如果應用伺服器沒有設計成無狀態或資料外部化時，必須把負載 均衡器設定sticky sessions，確保同一位使用者在sticky時間內， 都配派到同一台伺服器，並使用集中式session儲存伺服器，如 Redis、Hazelcast、Ignite等，確保分派到其他伺服器可保留狀 態，其他共用檔案，則透過NFS掛載，或是寫到資料庫來達到 stateless設計。 原因(Why)： 雖然購買更多CPU和記憶體的硬體設備，無須改寫程式，但單台伺服 器仍有交易處理上限，無法根本解決問題，而增加副本數量，則增加 維運成本。
- 9. 原則三：資料X軸擴展 說明(What)： 透過複製相同資料庫來分攤大量交易的資料讀與寫。 場景(When)： 資料庫讀寫比例很高，CPU使用量高，回應時間過慢。 方法(How)： ◼ 使用資料庫本身抄寫機制，將單一資料庫複製出多個副本，達到 讀寫分離。 ◼ 存取資料庫的應用程式需要改寫，區分出只讀或只寫(為了交易一 致性，insert或update之前的select可一同執行)的業務邏輯。 原因(Why)： 當資料庫無法配合業務快速成長，雖可購買更高等級資料庫，但單台 仍有交易處理上限，無法根本解決問題，而增加副本數量，須購買抄 寫工具並增加維運成本。
- 11. MySQL Scaling Solution Application nodes using a virtual IP to access read replicas 資料來源： High Performance MySQL, 4th Edition [Book] - O'Reilly Media
- 13. 原則四：服務Y軸擴展 說明(What)： 通常稱為服務拆分，沿著服務邊界或領域模型拆解相依的資料、系統 和開發團隊。 場景(When)： ◼ 當X軸擴展仍無法有效解決系統瓶頸。 ◼ 應用系統已經成為難以維護的大型複雜系統，開發團隊耗費大量 時間在溝通協調和系統功能耦合。 方法(How)： ◼ 透過業務領域將使用到的系統程式及資料表，拆出成獨立服務， 可參考資料表的ER Model或透過Domain Driven Design設計方 法。 ◼ 藉由APM監控了解系統瓶頸，將回應時間較長的服務，拉出成獨 立服務，檢視相依資料表，一併拉出成獨立資料庫。 ◼ 避免拆出的服務直接存取其他服務之資料表或資料庫，避免當異 動欄位時，連帶影響到其他外部服務，遵循Database per service (https://microservices.io/patterns/data/database- per-service.html)設計模式。 原因(Why)： 讓應用系統及相關資料庫可有效擴展，亦可讓開發團隊有效率增加， 且Y軸以面向業務領域方式拆分，有益於故障隔離，獨立的預約登記 活動系統，不會影響到一般線上交易系統。 DM1 DM2
- 14. 原則五：資料Y軸擴展 說明(What)： 將資料庫分成OLTP和OLAP角色，線上交易作業和BI報表作業分開。 場景(When)： ◼ 當X軸擴展仍無法有效解決資料庫瓶頸。 ◼ 資料庫讀寫比例很高，CPU使用量高，回應時間過慢。 方法(How)： ◼ 使用資料庫本身抄寫機制，將單一資料庫複製出多個副本，達到 讀寫分離。 ◼ 導入OLAP解決方案，如Data Warehouse，專用數據分析平台。 ◼ 相關OLAP作業，從唯獨副本執行報表分析或資料分析。 原因(Why)： 大量批次報表和數據分析工作，占用一般交易作業資料庫大量運算資 源，從資料庫作業型態拆分，無須異動程式，修改資料庫連線設定， 輕易就可達到資料庫分流。 Batch Jobs DM1 DM2
- 16. 原則六：服務Z軸擴展 說明(What)： 通常根據使用者的獨特屬性，例如省份、州、國籍、地理位置等進行服務分流。 場景(When)： ◼ 全球性服務，因地理位置的網路物理距離成為系統效能瓶頸。 ◼ 持續面對快速增長的使用者數量，建立高可用及備援機制。 方法(How)： ◼ 基於HTTP，使用Global HTTP Load Balancer雲端服務，如AWS Application Load Balancer、GCP External HTTP(S) Load Balancing和 Azure Public Load Balancer，或是網路設備商的解決方案，來達到 Content-based Routing，但只支援HTTP通訊協定。 ◼ 基於DNS，使用支援動態DNS的負載平衡服務，在客戶端查詢DNS解析時， 根據客戶端IP回傳最近的服務位置(geoproximity routing)，通常還會結合 CDN靜態網頁內容託管服務，如Amazon Route 53、Azure DNS、GCP Cloud DNS和Cloudflare等。 ◼ 前端靜態網頁的JavaScript程式配合後端Content-based Routing設計分流 邏輯判斷規則 原因(Why)： 當X軸服務擴展已經無法解決客戶快速增長，而Y軸服務擴展需要人力和時間來拆 分服務；且需要針對目標客戶群進行必要的故障隔離，亦可避免單一區域的網路 中斷或災難停止服務後，影響到整體服務可用率，但multi-region active-active architecture硬體及維運成本高，建議導入infrastructure as code方案來加速建 置並降低維運成本。 DM1 DM2 Batch Jobs GLB DM2
- 17. 原則七：資料Z軸擴展 說明(What)： 通常稱為資料Sharding或分片，有垂直分片或水平分片，根據資料屬 性來切分。 場景(When)： ◼ 當X軸擴展仍無法有效解決資料庫瓶頸。 ◼ 筆數非常大的單一資料表造成資料庫執行效率過低而影響業務功 能，且短期無法優化或修改程式拆分為多個資料表。 方法(How)： ◼ 避免採用垂直分片，除非是因業務邏輯而改變，否則將涉及大量 程式修改，水平分片可基於年份切割成不常用的冷資料與熱資料， 將超過保存年限的資料歸檔備分；亦可基於國籍、地理位置，配 合原則六：服務Z軸擴展的分流方式，或是多租戶架構設計，分 開存放到不同資料庫。 ◼ 導入自動分片的資料庫解決方案，避免大量程式修改，如果採用 非原先的異質資料庫，但須注意是否與現有資料型態schema相 符合，以及可能延伸出的轉換工作。 原因(Why)： 藉由水平分片可以解決單一節點資料庫效能問題，減少index索引大 小加速搜尋速度，解決大量資料筆數效果顯著，新式自動分片的資料 庫解決方案，如GCP Cloud Spanner可同時改善資料庫和跨區域資料 一致性問題。 DM1 EG2 EG1 EG3
- 18. 資料庫分片原理簡介 分片策略對於確定哪個記錄進入哪個分片是必要的： • Key-Based：其中一列稱為shard key，通過散列函 數放置。結果確定該行的分片。也稱為基於哈希的分 片或算法分片。 • Range-Based：例如，給定一個產品價格數據庫，範 圍 0-49 的價格進入分片 1，50-99 進入分片 2，依 此類推。價格列是分片鍵。如果商店銷售更多的低價 值產品，這將導致不平衡的分片和熱點。 • 基於字典：使用查找表。這是一種靈活的方法，因為 沒有預先確定的hash函數或範圍。一個示例是按客戶 所在的地區（例如英國、美國或歐盟）進行分片。 • Hierarchical：行和列的組合用作分片鍵。前面提到 的分片策略可以用在 key 上。 • Entity Groups：為了方便跨多個表的查詢，此策略 將相關表放在同一個分片中。這帶來了更強的一致性。 例如，與用戶有關的所有數據都駐留在同一個分片中。
- 19. Vitess簡介，來自YouTube的內部開發計畫 Vitess建立於2010年，目的在解決YouTube的下述MySQL 可擴展性問題： 1. YouTube的MySQL資料庫到達了峰值流量超過資料庫服 務容量的情況。為了暫時緩解這個問題，YouTube為寫 入流量建立了一個主要資料庫，為讀取流量另建了一個 副本資料庫。 2. 由於對觀看影片的需求是過往以來最高，因此只讀流量 仍然會讓副本資料庫超載。因此，YouTube增加了更多 副本資料庫，再次提供了臨時解決方案。 3. 最終，寫入流量變得太高，主資料庫無法處理，必須對 數據進行分片以便處理寫入流量。 （如果資料庫的整體 大小對於單一MySQL實例來說太大，則也需要進行分 片。） 4. YouTube的應用系統層也有經過修改，因此在執行任何 資料庫操作之前，程式可以識別正確的資料庫分片來執 行該查詢。 Vitess在應用程序和資料庫之間引入代理來路由和管理資料 庫交互。透過中間層代理，讓Vitess可具備橫向擴展能力的 資料庫平台。 The Database Category of CNCF Landscape
- 20. Vitess架構 一個Vitess叢集中有以下幾種角色。 一個或多個MySQL主備叢集。每個MySQL主備 叢集由一個MySQL主服務器和一個或多個 MySQL從服務器組成。 每個MySQL主備叢集都對應一個VTTablet程序。 該程序負責與此MySQL主備叢集通信，執行與此 MySQL主備叢集上的SQL命令。 Topology服務，負責維護Vitess叢集的 metadata，例如某個資料庫的各個分片都存儲在 哪些MySQL主備叢集上。在Vitess中，每個分片 都儲存在一個單獨的MySQL主備叢集中。 VTGate程序，對外提供MySQL單一入口，提 供Vitess client連接，如同使用一個單獨的 MySQL實例一樣。 VTGate透過查詢Topology服務來得到數據的存 放位置，然後進行SQL的拆分，並將各個子SQL分 發給各個VTTable進程，待各個VTTablet回傳結 果後，再由VTGate將結果進行聚合、排序，最後 返回給client端。 A S A S A S 資料來源： High Performance MySQL, 4th Edition [Book] - O'Reilly Media
- 21. Z軸擴展的優劣分析 Y軸處理不同服務的拆分，沿著業務領域或服務 邊界，Z軸則是單一服務的分割或Data Center異 地多活（AA mode），例如可依照customer_id 取mod將單一表格拆成多表，或是轉移年份久遠 的舊資料到另一台資料庫，避免筆數造成資料存 取瓶頸；也可利用IP地理位置將客戶導向同一地 區的Data Center達到客戶分流；產品目錄可以 按照 SKU 拆分，內容可按 content_id 拆分。 ◼ 提高了交易可擴展性、可用性，因部署到伺 服器的系統程式在Z軸上每個副本都是一樣的 （但數據是不同的），所以無法增加人員組 織的可擴展性，加速系統開發，加上資料快 取可讓伺服器使用較小的IaaS規格，降低硬 體成本支出。 ◼ 故障隔離的高可用架構，在美國有2個獨立的 以客戶切分的機房pod，在歐盟有2個。而Z 軸的另一個好處是可對pod進行分割，以便 符合當地的個資法，例如歐盟的GDPR。 出處：https://akfpartners.com/growth-blog/scale-cube
- 22. 原則八：善用公有雲服務 說明(What)： 有計畫地善用雲端平台技術隨需擴展。 場景(When)： ◼ 當業務需求是臨時性、突增的、偶發的，如搶購活動或預約搶票。 ◼ 開發新型態業務面對未來需求的不確定性，可避免投入大量資金 建置機房採購硬體設備。 ◼ 企業建置HA/DR資料中心 方法(How)： ◼ 利用第三方雲端環境滿足臨時性需求，例如季節性業務增加、大 量批次作業或新系統開發DEV環境和測試驗收的QA環境。 ◼ 配合原則六：服務Z軸擴展設計，將業務需求分流到雲端服務， 並在雲端架構規劃原則二：服務X軸擴展達到auto scaling，待業 務量下降減少運算資源，活動結束後移除雲端服務。 原因(Why)： 在本地端建置臨時性需求的硬體設備和應用系統需要數周時間，在雲 端環境，利用自動化建置腳本（infrastructure as code），如 Terraform、Pulumi，卻只需要幾分鐘，雖然前期需要學習這些工具 並實驗，但這項投資卻是非常划算。
- 23. 原則九：選擇適當資料庫 說明(What)： 當需要ACID屬性來維持資料之間的關係和一致性時，使用關聯性資料 庫；其他類型的數據儲存可考慮更適當的NoSQL資料庫。 場景(When)： ◼ 當在系統架構中準備匯入新資料或資料結構時。 ◼ 規劃獨立新系統時，根據業務情境選擇適當資料儲存解決方案， 如Web前端可採用JSON物件的文件式資料庫，搜尋引擎則可採 用Elasticsearch。 方法(How)： 綜合考慮數據量、儲存量、回應時間和關聯等因素，選擇最適當的儲 存工具，同時考量資料的結構型態，以及資料庫產品需要對數據進行 的管理和操作方式。 原因(Why)： 關聯式資料庫提供了嚴格的交易一致性，但成本很高且難以擴展，為 數據選擇正確的儲存工具，以便更輕鬆解決資料存取問題。而資料庫 技術方案選型，可參考SQL vs. NoSQL Database: When to Use, How to Choose（https://towardsdatascience.com/datastore- choices-sql-vs-nosql-database-ebec24d56106）。
- 24. SQL vs. NoSQL Database: When to Use, How to Choose https://towardsdatascience.com/datastore-choices-sql-vs-nosql-database-ebec24d56106
- 25. 原則十：務必使用分散式監控系統 說明(What)： 使用可觀測性（observability）的分散式解決方案來診斷和預防系統 問題。 場景(When)： ◼ 當服務X軸擴展和Y軸擴展後，大量應用系統監控成為維運負擔。 ◼ 可動態擴展的分散式架構，很難輕易清楚判斷根本問題，避免單 一服務問題，造成整個系統中斷或服務阻斷雪崩。 方法(How)： 可觀測性方案分成logging日誌、metrics指標和tracing追蹤，由於 auto scaling會自動刪除副本，需要將這三大資料作集中式儲存及分 析，以便確認問題發生時間先後，或依據監控數據來規劃運算資源， 如圖11。 原因(Why)： 若能充分使用監控數據，可迅速判斷定位根本問題點，而不是開發人 員與基礎系統人員霧裡看花，沒人可清楚看清事件發生順序，導致相 互指責。
- 27. 原則十一：設計分層快取機制 說明(What)： 減少從入口WAF到底層資料庫的網頁請求量，可節省網路頻寬和設備資源。 場景(When)： ◼ 當前端網頁傳輸佔據大量對外頻寬，影響到後端API資料傳輸。 ◼ 思考如何減輕運算成本最高的核心系統負擔。 方法(How)： 1. 把前端網頁靜態檔案放置到CDN服務，讓大量網頁內容請求從CDN機房讀取，節 省對外頻寬傳輸量。將異動頻率低的動態網頁內容轉換成靜態網頁內容，以便供 CDN託管。 2. 開啟網路設備快取機制，減少動態資料往後端讀取次數。 3. 使用Web、Reverse proxy反向代理或API Gateway快取機制。 4. 配合原則二：服務X軸擴展和原則四：服務Y軸擴展，設計應用伺服器的集中式快取 架構，如Redis、Hazelcast、Ignite等。 5. 使用存取資料庫程式的Object/Entity快取功能，如JPA cache或Hibernate cache 等。 6. 使用資料庫自身的快取解決方案，如memory table、IMDG等。 原因(Why)： 如同CPU設計L1/L2/L3快取架構，若能充分使用快取和資料命中率，可提升整體運算能 力。 1. CDN是Web架構普遍用來紓解流量高峰，分攤靜態檔案傳輸量，是經濟且簡單的 方式，且可提供全球客戶來源監控。 2. 善用網路設備的快取機制，可加速應用程式或網站時的載入時間，以便提高應用系 統或網站的性能和效率。 3. 將每周或每天才更新的動態內容放置到Web快取，可減輕應用伺服器負擔。 4. 善用應用伺服器的集中式快取架構，才能無狀態橫向擴展（X軸），並提供跨業務 領域的資料共用和數據分析能力（Y軸）。 5. 當有大量且重複的資料庫查詢時，使用Object/Entity快取可減輕資料庫負擔。 6. 使用資料庫的快取方案是成本最高的，且可能會被廠商綁定。
- 28. Cache Everywhere Client Tier Web Tier Gateway Tier Service Tier Storage Tier In Memory Replicate API Browser Storage Cache Edge/CDN Cache Gateway Cache Application Cache Storage Cache More expensive
- 29. 原則十二：適時採用非同步通訊方式 說明(What)： 透過Message Broker（MQ或Kafka）設計非同步式通訊，或使用響應式（Reactive） 開發框架，來拆解服務溝通方式。 場景(When)： ◼ 當採用同步式通訊的服務成為瓶頸，影響到整體效能。 ◼ 當無法增加硬體設備來改善系統效能時，修改既有架構設計或改成非阻塞式的響應 式程式設計。 方法(How)： ◼ 從業務流程分析或事件風暴（Event Stoming），了解現有流程能否用非同步方式 取代，如星巴克的兩階段交付，先結帳再叫名字取餐 （https://www.enterpriseintegrationpatterns.com/docs/IEEE_Software_Desi gn_2PC.pdf）。 ◼ 參考經典企業整合模式 (Enterprise Integration Patterns， https://www.enterpriseintegrationpatterns.com/)一書來設計非同步整合架構。 ◼ 將訊息（Message）分成需確認結果的命令（Command）和單純傳遞已發生的事 件（Event），命令使用支援Request-Reply的MQ，事件則使用Fire & Forget的 可擴展Event Bus方案，如Kafka等。 ◼ 確保Event Bus不會成為瓶頸點，必需可隨業務量橫向擴展。 ◼ 非同步通訊增加問題查找的困難度，務必導入分散式監控機制。 ◼ 仿效敏捷宣言，亦有響應式宣言（https://www.reactivemanifesto.org/），屬於 新程式設計理念，目前支援Java的框架有Spring Webflux、Vert.x、RxJava等。 ◼ 資料庫存取程式亦有響應式Client，如R2DBC和Reactive SQL Client等，避免過 多的資料庫連線造成資料庫效能問題。 原因(Why)： ◼ 使用非同步通信技術確保每個服務和應用分階可各自獨立，而同步式則讓所有元件 緊密耦合，非同步方法可透過Message Broker讓系統順利擴展。 ◼ 響應式開發框架內建了非阻塞、容錯高可用、Event Bus可伸縮等特性，在新系統 或高流量的服務中可導入響應式程式設計，改善執行效率避免服務壅塞。
- 30. Your Coffee Shop Doesn’t Use Two-Phase Commit 外部相依服務成為瓶頸時，可考慮使用非 同步方式： Client使用結帳API 結帳API寫入Queue 透過topic訂閱的對外專用API收到通知 對外專用API呼叫Partner信用卡API 外部信用卡API回傳結果 對外專用API收到結果寫入資料庫 結帳API查詢交易結果 https://www.enterpriseintegrationpatterns.com/docs/IEEE_Software_Design_2PC.pdf
- 31. 前端效能優化方面 1. 缩短请求耗时 1.1 优化打包资源 1.2 CDN加速 1.3 浏览器缓存 1.4 更高版本的HTTP 1.5 Web Socket 1.6 服务器端渲染（SSR） 2. 减少重排重绘 2.1 减少渲染量 2.2 减少渲染次数 3. 改善JS性能 3.1 缓存复杂计算 3.2 Web Worker 3.3 Web Assembly https://insights.thoughtworks.cn/web-frontend-performance-tuning/
- 32. IaaS An Overview of Enterprise IT Technology Architecture Enterprise API Management Enterprise Gateway Web/Mobile Services Partners Traffic Outer API BFF Service Application Server Application Service PaaS Managed Container System MeshProxy Inner API Miniservice Proxy Inner API Miniservice Proxy Inner API Miniservice Proxy Inner API Miniservice Administration Portal Consumers Channel Inner API Service Inner API Service Application Service Inner API Service Platform API Management Microgateway IoTs ChatBot Enterprise Service Bus ODS TMS BaNCS CardLink IFX Accounting G/L DB Pool DB Pool VM Container
- 34. Q&A