《從0開始學架構》《大型網站架構設計》讀書筆記

時間 2019-11-05

原文原文鏈接

前言

每個程序員都有一個架構師的夢，可理想很豐滿，現實很骨感---大部程序員工做中都作着簡單的 CRUD，我也不例外。若是就這樣還常把「架構」兩個字掛在嘴邊，估計程序員們都會臉紅。但就由於暫時還不能成爲架構師，咱們就要放棄成爲架構師的夢想了嗎？顯然不能，掌握架構設計的相關理論是成爲架構師的前提，有了方法論能夠更好地指導咱們幹活。機會老是留給有準備的人的，萬一哪天夢想實現了呢？css

爲了學習「架構」，我偷偷的看了兩本武功祕籍《從 0 開始學架構》《大型網站技術架構》。並從中發現了一些祕密：兩本書講的關於架構的核心內容有不少共同的地方，這說明了什麼？說明了架構師是有套路的。掌握了套路並敢於實踐，將來並不遙遠。html

架構的前世此生

一、什麼是架構

在理解什麼是架構以前，先來看下與它相關的一些詞彙：架構、框架、組件、模塊和系統。《從0開始學架構》下的一條評論很精煉的總結了它們的定義與區別，摘抄以下：前端

架構是頂層設計；框架是面向編程或配置的半成品；組件是從技術維度上的複用；模塊是從業務維度上職責的劃分；系統是相互協同可運行的實體。程序員

軟件架構是軟件系統的頂層設計，它明確軟件系統包括哪些個體：子系統、模塊和組件等；同時明確了個體運做和個體之間協做的規則。面試

二、架構的歷史背景

從機器語言到彙編語言到高級語言、從結構化程序設計方法到到面向對象編程思想到面向接口編程、從單機單進程到單機多進程到分佈式集羣。每一次語言、編程思想和技術的升級都是爲了知足軟件規模愈來愈大的須要。而隨着軟件系統大到必定程度，數據結構與算法再也不構成軟件設計的主要問題；當系統組成部分愈來愈多時，整個系統的組織或者說「軟件架構」致使了一系列新的問題。而不合理的架構的複雜系統每每面臨以下問題：算法

系統規模龐大，內部耦合嚴重，開發效率低；
系統耦合嚴重，牽一髮而動全身，後續修改和擴展困難；
系統邏輯複雜，容易出問題，出問題後很難排查和修復。

軟件架構便應運而生，但因爲軟件系統的複雜性和多變性，沒有一種架構能夠知足全部系統的設計需求。它與面向對象編程、軟件工程同樣，不是軟件設計領域的銀彈。sql

三、架構設計的目的

作任何事情只有明確了目的，才能把握方向，從而制定方案並執行，架構設計也不例外。架構設計的主要目的是爲了解決軟件系統複雜度帶來的問題。小到管理系統大到淘寶、微信，在設計開發過程當中，都須要進行架構設計。而因爲軟件系統之間的複雜度不一樣，架構設計難度也不同，但基本流程都類似，掌握了架構設計的流程，即便簡單的對內的工具平臺也能玩出花兒來。數據庫

四、架構做用的總結

架構設計可大可小但不是無關緊要，架構並非高不可攀也別嗤之以鼻。編程

一、架構是爲了應對軟件系統複雜度而提出的一個解決方案。後端

二、架構即(重要)決策。

三、需求驅動架構，架起分析與設計實現的橋樑。

四、架構與開發成本的關係。

架構設計理論

一、架構設計複雜度來源

軟件架構定義中咱們老是能看到複雜軟件這個詞，什麼是複雜軟件呢？大規模網站就是複雜軟件的一種，大規模網站架構（其餘軟件系統也相似）須要考慮的複雜度來源主要以下圖所示：

包括高性能、高可用、易擴展、可伸縮、安全性和低成本六個來源。 注：爲了更具化的說明軟件架構設計本文使用大規模網站做爲複雜軟件來說解

大部分程序員畢生所學除了用來作業務邏輯開發，大部分技能都是爲了解決以上六個問題。咱們看過不少書、寫過不少代碼、作過不少設計，今天終於在這裏找到了作這一切的根源。這顆大型網站架構要素的樹能夠將你看過絕大部分知識包含進去，是你結構化腦海中知識的根。只要你的知識夠豐富，一層層的掛上去，這棵樹能夠獨木成林。這也是是我寫這篇文章的目的，並不僅是簡簡單單的複製和總結。也是想告訴絕大部分程序員：經過這棵樹開始結構化你腦海中的知識吧。

架構設計三原則（來源於網絡）

一、合適原則：合適優於業界領先。

架構無優劣，但存合適性。「汝之蜜糖，吾之砒霜」；架構必定要匹配企業所在的業務階段；不要面向簡歷去設計架構，高大上的架構不等於適用；削足適履與打腫充胖都不符合合適原則；所謂合適，必定要匹配業務所處階段，可以合理地將資源整合在一塊兒併發揮出最大功效，並可以快速落地。

二、簡單原則：簡單優於複雜

"我沒有時間寫一封短信，因此只好寫一封長信"。其實，簡單比複雜更加困難。面對系統結構、業務邏輯和複雜性，咱們能夠編寫出複雜的系統，但在軟件領域，複雜表明的是「問題」。架構設計時若是簡單的方案和複雜的方案均可以知足需求，最好選擇簡單的方案。可是，事實上，當軟件系統變得太複雜後，就會有人換一個思路進行重構、升級，將它從新變得簡單，這也是軟件開發的大趨勢。簡單原則是一個樸素且偉大的原則，Google的 MapReduce 系統就採用了分而治之的思想，而背後就是將複雜問題轉化爲簡單問題的典型案例。

三、演化原則：演化優於一步到位

大到人類社會、天然生物，小到一個細胞，彷佛都遵循這一普世原則，軟件架構也不例外。業務在發展、技術在創新、外部環境在變化，這一切都是在告誡架構師不要貪大求全，或者盲目照搬大公司的作法。應該認真分析當前業務的特色，明確業務面臨的主要問題，設計合理的架構，快速落地以知足業務須要，而後在運行過程當中不斷完善架構，不斷隨着業務演化架構。

架構設計三原則很重要，在設計你的軟件系統以前先問問本身這樣作架構合適嗎？簡單嗎？可演化嗎？

架構設計流程

一、識別複雜度

在作軟件系統開發的時候不可能一上來就直接敲代碼，經常須要進行一些分析。除了功能上的分析，還須要對軟件系統複雜度進行分析，這決定了你後續方案的選型。

架構的複雜度來源雖然有六個，但主要複雜度來自於高性能、高可用和易擴展。在討論架構設計的時候咱們更多的是討論這三點，本文也不例外。

但架構並不必定任什麼時候候都必須知足這三個需求。根據軟件系統的不一樣，大部分狀況下只須要知足其中的一個到兩個，不多能用到三個的。

在進行高性能、高可用和易擴展複雜度來源分析的時候最好有指標支撐，好比高性能要達到多少 QPS、高可用要達到幾個九、可擴展要擴展到什麼程度。千萬不要憑本身想象，這樣要麼將複雜度分析的過於簡單，上線後不能知足需求；要麼將複雜度分析的過於複雜，致使過分設計，項目遲遲不能上線。

二、設計備選方案

解決高性能、高可用和易擴展三個複雜度來源的成熟的技術方案有不少。好比，高性能的緩存、負載均衡、多路複用，高可用的主備方案、集羣方案、異地多活，易擴展的設計模式、架構分層、插件化等。在明確了軟件系統的複雜度（三選N）之後就能夠按圖索驥的找到可選的解決方案。

架構師在設計方案的時候須要注意如下幾點，別落入俗套：

總想着設計最優秀的方案。
只作一個方案。
方案設計的過於詳細。

這就是爲何不少大公司的面試都喜歡問一些開源框架或者軟件的源碼，他們的目的不在於讓你熟悉源碼，而是在軟件系統架構設計時可以快速的對現有的各類框架進行選型以找出相對合適的。

三、評估和選擇備選方案

方案有了，還須要評估和挑選出最合適的方案。這裏須要遵照架構設計的三個原則合適、簡單和演化，但還會面臨如下挑戰：

每一個方案都必須是可行的
每一個方案都是不完美的
評價標準主觀性比較強

架構師對方案的選擇每每存在如下幾派：

最簡派：只選擇最簡單的
最牛派：只選擇最流行的
最熟派：只選擇最熟悉的

而正在的備選方案評估以上幾派都不靠譜，真正要作的是對各個方案進行 360度環評：**列出咱們須要關注的質量屬性點，而後分別從這些質量屬性的維度去評估每一個方案，再綜合挑選適合當時狀況的最優方案。**常見的方案質量屬性點有：性能、可用性、硬件成本、項目投入、複雜度、安全性、可擴展性等。根據大家團隊對以上各個屬性的側重點，選擇最合適的方案。

四、詳細方案設計

開始對備選方案進行一個詳細的設計，好比各個個體如何運行、個體與個體之間如何協做等。

在這一步的時候可讓一線開發來完成細節的填充，架構師作最後的審覈便可。一方面下降了架構師的工做量，另外一方面能夠培養新人。

總結

咱們從以上內容瞭解到軟件系統設計的發展歷史以及架構設計的定義、目的、使命、原則和流程這樣一個完整的閉環，爲接下來的架構設計實戰夯實了理論基礎。

架構設計實戰（以大型網站爲例）

高性能

高性能是架構設計複雜度來源之一，任何軟件系統對高性能都有所要求，只是要求的標準不同。對性能要求越高的軟件系統架構設計越複雜，反之越容易。但若是高不能用指標來量化，那便沒法進行合理的架構設計和進一步優化。因此高性能的兩部分性能指標和性能優化同等重要。

性能指標

評價大型網站高性能的主要指標以下：

響應時間：是一次請求從發送請求到收到響應的總時間，直觀的反映系統的快慢。
併發數：是單位時間處理的請求數，一般用TPS來表示，是系統容量的直觀體現。
吞吐量：是系統同時能處理的請求數。一般包括 TPS、QPS 或者 HPS。固然，光有指標的定義還不夠，還須要對這些指標有基本的量化，好比響應時間小於300ms、併發數不小於 1W 個連接，吞吐量達到 1W QPS等。

性能優化

大型網站從前臺到後臺再到數據可大體分爲三個層次，本文分別從三個層次來介紹性能優化所涉及到的技術點，但系統的性能優化方案歷來不該該是大而全的，這裏只是泛泛而談。若是這裏涉及到的知識點你不曾涉及，建議自行百度，弄懂後掛到腦圖樹上；若是對涉及到的知識點有着更深的理解，擴充你的腦圖樹葉。

一、Web 前端優化

減小 http 請求：因爲一次 http 請求中包含不少有效數據之外的無效數據（好比響應碼、header），因此儘可能將屢次 http 請求合併成一個，好比 js 文件與 css 文件合併、小圖片合併成一張大圖片等。

使用瀏覽器緩存：不少網站的 css、js、圖片這些靜態文件更新頻率很低，而這些靜態文件又須要頻繁請求，即可以將它們緩存到瀏覽器中。經過設置 http 頭中的 Cache-Control 和 Expirs 屬性，能夠設定瀏覽器緩存，緩存的時間能夠是數天或者幾個月。（http 協議 header 中各個字段的做用）

啓用壓縮：在服務器端返回數據之前進行數據壓縮，特別是 js/css/html 等文本的壓縮，壓縮率極高可達 80%。但數據的壓縮和解壓會給服務器端和瀏覽器端都形成必定的壓力，在設計時須要權衡。(數據壓縮算法有哪些)

減小 Cookie 傳輸：不要將大量的用戶數據放在 Cookie 中，一方面不安全，另外一方面會增長網絡傳輸壓力。最經常使用作法是將用戶數據存儲在 Session 中，Cookie 中只須要存入 Session ID 便可。（什麼是 Cookie/Session，以及它們之間的區別）

CDN 加速： CDN（Content Distribute Network，內容分發網絡)的本質仍然是一個緩存，它通常由網絡運營商提供，將數據（通常是靜態數據 js、css、圖片、文件等）緩存在在離用戶最近的地方。（什麼是 CDN）

反向代理： 反向代理工做在瀏覽器和後端服務器之間，它屏蔽了後端服務器的細節。一方面它能夠用來進行後端服務器的負載均衡，另外一方面能夠緩存靜態內容加速網站的訪問。（什麼是正向代理和反向代理）

二、應用服務器優化

使用緩存：緩存在提升性能方面隨處可見，從前端到後臺。前端前面已經介紹，然後臺服務的緩存分爲本地緩存和分佈式緩存（本地緩存與分佈式緩存各自的原理以及它們的優缺點）。

本地緩存可使用簡單的 Hash 表實現也可使用開源軟件，好比 SpringBoot 下的 Encache。（Hash 定義、如何避免衝突）。

分佈式緩存是比較經常使用緩存解決方案，特別是在集羣環境。分佈式緩存有不少成熟的開源軟件，好比 Memcached 和 Redis，因爲使用普遍，分佈式緩存原理和一些開源軟件是面試中的常客。（分佈式緩存的原理、Memcached 和 Redis 各自的優缺點，瞭解緩存中一些經常使用名詞：緩存穿透、緩存熱點、緩存雪崩等）。

異步操做：異步是提升性能的另外一個手段，也包括本地異步和分佈式異步。本地異步能夠用簡單的多線程或者線程實現，也能夠用成熟的事件框架，好比谷歌的 Guava Eventbus。而本地進程間可使用共享內存實現異步，只是須要在共享內存中實現一個併發安全的本地消息隊列。

分佈式異步可使用消息隊列，消息隊列不只能夠解耦系統還能夠削峯填谷。它是分佈式系統異步的終極解決方案，常見的消息隊列有 RabbitMQ、MetaQ、Kafka。（消息隊列的原理和 RabttiMQ 的優缺點）

使用集羣：一臺機器的性能再好，整個系統的吞吐量都是有限的。爲了支持更大的吞吐量，除了優化代碼、提升單機服務器性能，還能夠將系統從一臺機器部署擴散到多臺。所謂的分佈式系統都是這種操做，由於只有這樣才能破解摩爾定律失效的魔咒。

代碼優化：從代碼層面來提升性能是程序員必備技能，涉及到的知識點太多，這裏只簡單的列舉一下幾點，算是拋磚引玉：

（1）使用多線程、多進程。

（2）充分利用內存。

（3）資源複用：單例和池化技術。

（4）更好的算法和數據結構。

（5）JAVA 虛擬機參數調優以及避免 FULLGC。

（6）合適的 IO 模型和線程/進程模型。

三、存儲性能優化

磁盤 IO 優化：使用 SSD 代替機械硬盤，使用 HDFS 代替普通文件系統。 數據庫優化：數據庫優化是個老生常談的問題，也是面試中的常客。主要有如下幾種優化方法（高性能 Mysql）：

（1）增長索引

（2）優化SQL語句

（3）分庫分表

（4）讀寫分離

（5）分佈式關係型數據庫

（6）使用 Nosql

高可用

若是系統不可用，性能再高也沒卵用。與高性能同樣，高也須要有指標來量化，好比4個9。大型網站的高可用又分爲應用高可用、服務高可用和數據高可用。

高可用的服務

一、接口服務高可用

服務降級：將業務或者接口功能下降，只提供部分功能或者徹底停掉全部功能。常見實現降級方式有：系統後門降級和獨立系統降級。

流量限制：降級是故障後的過後處理，而限流是故障前的預防。限流是指只容許可以承受的訪問量進來，超出系統系統訪問能力的將被放棄。經常使用的限流方式能夠分爲分類：基於請求限流和基於資源限流。

流量排隊：是流量限制的一個變種，限流是直接拒絕用戶，排隊是讓用戶等待一段時間。 服務熔斷：熔斷與降級概念很是容易混淆，降級是爲了應對服務自身的故障。熔斷的目的是爲了應對外部系統故障的狀況：主動斷開依賴的其餘外部的不可用服務，防止形成更多的雪崩效應。

分級管理：根據服務功能的重要性按照等級進行劃分，將不一樣等級的服務進行隔離，防止非核心服務的故障影響核心服務。

二、業務服務高可用

集羣一、多機器部署

二、服務註冊與發現

異地多活：

一、同城異區+專線：複雜度低、有用性高、沒法應對大災難（如同城地震、停電）

二、跨城異地：複雜度高、網絡延遲高、數據沒法強一致性。並不是全部業務都適合。

三、跨國異地：缺點同跨城異地，主要用來：

爲不一樣地區提供不一樣服務，如亞馬遜中國/亞馬遜美國
只作只讀類業務多活，對延遲沒那麼敏感，如谷歌搜搜。

微服務

服務描述：服務描述用來描述服務的如下信息：（1）服務名稱（2）調用服務須要提供的信息（3）服務調用後返回的數據格式常見的服務描述包括 RESTFUL API、XML配置以及 IDL 文件三種。

註冊中心：經過註冊中心進行服務的發佈和訂閱。微服務分爲服務調用者和服務消費者，註冊中心是他們溝通的橋樑。

服務框架：提供服務消費者與服務提供者之間進行溝通的約定：（1）服務通訊採用什麼協議（2）數據傳輸採用什麼方式（3）數據壓縮採用什麼格式

服務監控：服務監控是瞭解服務是否可用的重要手段，主要包括三個流程：指標收集、數據處理和數據展現。

服務追蹤：除了須要對服務調用狀況進行監控以外，你還須要記錄服務調用通過的每一層鏈路，以便進行問題追蹤和故障定位。阿里鷹眼

服務治理：服務監控能發現問題，服務追蹤可以定位問題所在，而解決問題須要靠服務治理。負載均衡和故障自動轉移。

高可用的數據

一、數據一致性

CAP 理論：對於一個分佈式計算系統，不可能同時知足一致性（Consistence）、可用性（Availability）、分區容錯性（Partition+Tolerance）三個設計約束。CAP 關注的是對數據的讀寫操做而不是整個系統。CAP最多隻能知足三者中的兩個，P必須知足，注重一致性則必須是CP（如zookeeper），注重可用性則必須是AP（如eureka）。

ACID：ACID 是數據庫系統爲了保證事務的正確性而提出來的理論，ACID 包含四個約束：Atomicity（原子性）、Consistency（一致性）、Isolation（隔離性）和 Durability（持久性）。

BASE：BASE+是指基本可用（Basically+Available）、軟狀態（+Soft+State）、最終一致性（+Eventual+Consistency），核心思想是即便沒法作到強一致性（CAP+的一致性就是強一致性），但應用能夠採用適合的方式達到最終一致性。

二、數據備份

存儲高可用方案的本質都是經過將數據複製到多個存儲設備，經過數據冗餘的方式來實現高可用，其複雜性主要體如今如何應對複製延遲和中斷致使的數據不一致問題。所以，對任何一個高可用存儲方案，咱們須要從如下幾個方面去進行思考和分析：

數據如何複製
各個節點職責是什麼
如何應對複製延遲
如何應對複製終端

主備複製：

（優缺點分析）能夠衍生出一主一備、一主多備。備機只是單純的爲備份，並不進行讀寫操做。當主機故障不可用之後，須要人工干預切換到備機。主備架構的優勢是簡單，能夠直接利用 Mysql 提供的 binlog 便可實現。經常使用於學生管理系統、員工管理系統和假期管理系統等。

主從複製：

與主備複製一字之差，架構卻不同。主從複製中的主機負責讀寫，從機除了備份數據外還支持讀，優勢是主機故障不可用也不影響讀業務同時充分利用了硬件資源。缺點是

（1）客戶端讀複雜度提升，須要感知主從關係並選擇一臺機器進行讀操做。

（2）若是數據複製的延遲比較大，會出現數據不一致的中間態。

（3）故障時須要人工干預。

主主複製：

主主架構兩臺都是主機，主要優勢以下：

（1）兩臺主機均可以進行讀寫，其中一臺故障不影響總體業務。

（2）客戶端無需區分角色，能夠將讀寫請求發送到任意一臺機器上。

看似完美的主主架構也有衆多缺點：

（1）雙向複製也並不能保證明時性，若是延遲較高也會存在數據不一致的中間態。

（2）不少數據並不能進行雙向複製，好比用戶自增 id、庫存數據、餘額數據等。

主主複製架構對數據設計有嚴格要求，通常適合那些臨時性、可丟失、可覆蓋的數據場景。

數據集羣：上面介紹的不管是主備/主從/主主都只有一臺主機，它們有以下兩個缺點：、

（1）主機存儲的數據有限。

（2）主機宕機後須要手動恢復。

數據集羣由多臺機器組成造成一個系統，專門用來存儲數據。數據集羣又分爲數據集中集羣和數據分散集羣：

（1）數據集中集羣：集羣中機器上的數據都是同樣的，由一臺機器進行寫而後複製到集羣中其餘機器。可參考 zookeeper 的原理和架構。

（2）數據分散集羣：數據分散在不一樣機器上，固然也會備份在幾臺集羣中的機器上。可參考一致性哈希算法和 Amazon 的 Dynamodb 原理以及架構。

數據分區：將數據按照區域進行劃分，防止某個區域發生很是大的災難，好比洪水、地震、海嘯等。而每一個區域的數據備份又能夠採用上述的主主/主從/主備/集羣的方式保證高可用。數據分區架構複雜度須要從如下方面去考慮：

（1）數據量

（2）分區規則

（3）複製規則：集中式、互備式和獨立式

高可用的質量保證

一、網站發佈：在柔性的發佈過程當中，每次關閉的服務都是集羣中的一小部分，並在發佈完成後當即能夠訪問；

二、自動化測試：使用自動測試工具或腳本完成測試；

三、預發佈驗證：引入預發佈服務器，與正式服務器幾乎一致，只是沒有配置在負載均衡服務器上，外部用戶沒法訪問；

四、代碼控制：目前大多數網站採用SVN，分支開發，主幹發佈模式；另外，目前開源社區普遍採用Git做爲版本控制工具，正逐步取代SVN的地位；

監控和告警

一、監控數據採集

（1）用戶行爲日誌收集：服務器端的日誌收集和客戶端的日誌收集；目前許多網站逐步開發基於實時計算框架Storm的日誌統計與分析工具；

（2）服務器性能監控：收集服務器性能指標，如系統Load、內存佔用、磁盤IO等，及時判斷，防患於未然；

（3）運行數據報告：採集並報告，彙總後統一顯示，應用程序須要在代碼中處理運行數據採集的邏輯；

二、監控管理

（1）系統報警：配置報警閥值和值守人員聯繫方式，系統發生報警時，即便工程師在千里以外，也能夠被及時通知；

（2）失效轉移：監控系統在發現故障時，主動通知應用進行失效轉移；

（3）自動優雅降級：爲了應付網站訪問高峯，主動關閉部分功能，釋放部分系統資源，保證核心應用服務的正常運行；

易擴展

這個世界惟一不變的是變，與建築架構不一樣，軟件系統架構是一個不斷演變的過程。若是軟件系統從一開始沒作好軟件架構，遇到每次大的改變都須要重構，將是不能接受的。

核心思想

可擴展性架構設計方式有不少，但萬變不離其蹤，全部的可擴展架構的背後基本思想均可以總結爲一個字："拆"。

拆分思路

按照不一樣的思路來拆分軟件系統，就會獲得不一樣的架構。常見的拆分思路以下：

面向流程拆分：將整個流程拆分紅一個階段，每一個階段做爲一部分。
面向服務拆分：將系統提供的服務進行拆分，每一個服務做爲一部分。
面向功能拆分：將系統提供的功能進行拆分，每一個功能做爲一部分。

更具體的例子：

流程對應+TCP/IP+四層模型，由於+TCP/IP+網絡通訊流程是：應用層 → 傳輸層 → 網絡層 →物理+數據鏈路層，無論最上層的應用層是什麼，這個流程都不會變。

服務對應應用層的+HTTP、FTP、SMTP+等服務，HTTP+提供+Web+服務，FTP+提供文件服務，SMTP+提供郵件服務，以此類推。

功能每一個服務都會提供相應的功能。例如，HTTP 服務提供 GET、POST 功能，FTP 提供上傳下載功能，SMTP 提供郵件發送和收取功能。

面向流程拆分更像縱向拆分，面向服務拆分更像橫向拆分，面向功能拆分是比面向服務更細的拆分。它們之間並非非此即彼的，而是相輔相成的。一個系統的架構既可能用到面向流程拆分也可能用到面向服務拆分，甚至面向功能拆分。

已有架構

面向流程拆分：分層架構面向服務拆分：SOA、微服務面向功能拆分：微內核架構

一、分層架構和 SOA

分層架構：比較常見，最簡單的例如將系統分爲應用層、服務層和存儲層。複雜的軟件系統還會分更多的層次。分層架構須要保證各層之間的差別足夠清晰，邊界足夠明顯，讓人看到架構圖後就能看懂整個架構。傳統的分層架構：

SOA（Service Oriented Architecture）架構：提出服務、ESB 和鬆耦合三個概念，爲微服務的出現提供了理論支撐。典型的 SOA 架構：

二、微服務

微服務的英文定義：In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery.

微服務的關鍵詞：small、lightweight 和 automated。微服務須要的基礎設施：