服務與架構的演化

Gen.1 Cleint/Server or Browser/Server架構

這時代主要是C/S或者B/S模式的應用與架構, 主要是面向功能來實現業務. 像是我們需要FTP或者一個能提供靜態網頁的伺服器. 這也是所謂的單一架構(Monolithic Architecture). 常見的開發流程往往是根據ER Model設計出資料表, 然後進行CRUD操作.

特點就是一個業務功能形成完整的閉環應用.

優點:

開發快速
成本低
週期短

缺點:

程式都集中在一個項目, 很難協同開發
系統高度集中, 任何問題都可能導致整個系統癱瘓, 穩定性很差
程式碼耦合程度高, 後期維護複雜, 功能擴展困難
業務變更或系統整合時往往會導致需要重構甚至重作整套系統, 迭代時間就很難像一開始那樣快速
完全綁死在某種語言之下

Gen.2 分佈式系統/功能組件

因為前一個世代導致巨大臃腫的系統, 難以管理. 很難兼顧高質量的交付. 開始有了"高內聚"、"低耦合"、"容易擴展"、"集成"、"模組化"的概念. "OOP"和"組件Component"的概念由然而生. 也有了Application server這概念, 也對業務進行分層架構(MVC)、橫切關注點AOP、DI/IoC. 出現了中間件(MiddleWare)這些設計模式等概念.

特點就是一些獨立組件, 多層的模式, 關注點分散, 合理的界面定義(SRP), 每一層可以再分出自己的Business Logic模組, 增加功能模組的可重複使用性. But,就還是以單一架構的架構存在

優點:

不同模組可以用不同技術實現了
分層設計, 不同層的處理可以作成Cluster, 增加覆載量

缺點:

很多架構沒把資料庫拆開分層, 所以資料庫變成瓶頸
就算資料庫拆開分層, 因為資料是透過介面調用來作為傳遞, 此時就匯產生資料同步議題
此時系統劃分的方式還是以功能單位進行, 稱為"垂直架構", 但因為個別系統的能力還是有限且不可靠, 依舊可能出現單點失敗

Gen.3 SOA面向服務流程架構

很容易導致同公司但不同業務線由不同的開發團隊負責. 技術語言不同, 資料庫也不同, 彼此不相互溝通. 就是各自獨立的"煙囪式系統". 這種架構會導致重複開發, 因為不同部門之間技術允許不同, 所以可能會出現同功能的模組, 用不同語言開發. 系統之間打通成本頗高.

當然若是業務線就一組, 就沒差了:D

SOA的幾個特徵:

封裝服務
低耦合
服務契約化
服務抽象化
服務重複利用化
服務組合化
服務自治化
服務的可優化
無狀態服務
服務的可尋性

為此我們把服務流程的思維, 拆解成多個不同的步驟, 每個步驟的實現都可以定義成一個功能組件.

WebService

每個組件用"Web Service"的方式進行包裝. 這樣就能達成技術實現的隔離性.

每個服務之間透過WSDL定義服務界面,透過SOAP進行調用資料編碼,傳輸. 服務之間透過UDDI進行服務發現後然後訪問.

Web Service實現了服務能運行在不同台機器和OS上, 且服務間相互發現和呼叫調用的可能, 並且透過協議傳輸資料.

ESB 企業服務總線

ESB廣義來說就是一根管道, 用來連接各個服務節點. ESB的存在就是為了集成基於不同協議間的不同服務. ESB做了訊息的轉化跟路由的工作, 能讓不同的服務之間互通有無. 所以它才會被稱為"總線".

通常也會用MessageQueue來實現服務之間依賴的解耦合, 替服務提供異步處理能力. 解決因併發同步調用資源造成的問題, 達到"限流&削峰"的作用.

優點講說了很多, 講講缺點:

資料庫依然沒分開, 很多時候就使用一個DB做OLTP, 成為了瓶頸
服務管理依然不太完善
學習門檻很高
SOAP傳輸的內容往往大部分字段是沒太大價值的, 降低了吞吐量
SOA對界面規範和協議標準非常高, 不方便實施與推廣
光是透過ESB和服務交互, 就出現了4次的網路會話和資料傳輸, 效率不高
ESB雖然可以做Cluster但很容易產生"雪崩", 因為只要在高負載情況下, ESB掛掉一台, 基本上其它台也扛不住死掉那台的壓力,跟著罷工.

因此後面出了REST和JSON, 來改善這部份的缺陷.

Gen.4 微服務架構(Micro Services)

由於有輕量級REST協議、Container、輕量級通訊協定(JSON,protobuf、messagepack)、Service Registry、PaaS、Iaas等科技的出現. 加上微小的服務架構能夠很好彌補SOA的一些缺陷, 因為SOA沒法滿足業務的快速變化, 且當時還不盛行雲服務.

微服務目的不只是流程的解構, 更希望能圍繞在業務上(DDD)開發, 也讓小團隊也能快速開發迭代.

微服務其實沒非常準確的定義, 但有一些基本特點:

使用一些相對于SOA小的服務來開發單體應用, 相互協同工作, 並各自自治
每個服務運行在自己的process中
使用輕量級協議(RESTful APIf、gRPC)做通訊(Lightweight Mechanism)
服務是圍繞在業務能力(Business Capability)來區分規劃, 使用者情境和流程便於我們劃分服務
透過自動化部屬來完成獨立部屬, 灰度測試
服務可以使用不同的語言來開發, 也可以使用不同的資料儲存媒介.
保持最低限度的集中式管理
還是會用到SOA的相關技術

微服務的維度

業務微服務

基於業務角度來描述微服務組件, 例如會員微服務, 訂單微服務, 商品微服務

技術微服務

從技術方面就是技術微服務, 快取緩存微服務, 檔案文件微服務, 數據微服務, 安全驗證微服務...

微服務架構的缺點

多服務運維難度大幅增加
系統部屬依賴度提高, 服務管理成本增加
服務之間的通訊成本增加
數據一致性成為大問題
技術成本高, 團隊挑戰難度增加

Gen.5 Service Mesh服務網格

nginx what-is-a-service-mesh

Control plane: 集中配置與管理Service Mesh, 像data plane代理發送配置與控制訊號.
Data plane: 透過sidecar proxy這層代理, 接收並且控制網格內不同服務之間所有的出入網路數據; 達成全鍊路追蹤的目的. ...我也不熟, 期待下次鐵人賽之前能有機會玩到

DDD社團

微服務瞎談(2) 服務與架構的演化