一剔宪、微服務(wù)簡介

A.單體地獄

1.成功的應(yīng)用有一個趨勢葱绒，隨著時(shí)間推移而變得越來越臃腫

2.復(fù)雜的單體應(yīng)用本身就是持續(xù)部署的障礙

3.單體應(yīng)用使得采用新框架和語言變得非常困難

B.微服務(wù) — 解決復(fù)雜問題

1.思路是將應(yīng)用程序分解成一套較小的互連服務(wù)地淀。一個服務(wù)通常實(shí)現(xiàn)了一組不同的特性或功能。每個微服務(wù)都是一個迷你應(yīng)用，包括了業(yè)務(wù)邏輯以及多個適配器

2.一些微服務(wù)會暴露一個供其他微服務(wù)或應(yīng)用客戶端消費(fèi)的API作箍，其他微服務(wù)可能實(shí)現(xiàn)了一個WebUI胞得，在運(yùn)行時(shí)阶剑，每個實(shí)例通常是一個云虛擬機(jī)（virtual machine,VM）或者一個Docker容器

3.他們之間的通信是由一個被稱為API網(wǎng)關(guān)（API Gateway）的中介負(fù)責(zé)牧愁，API網(wǎng)關(guān)負(fù)責(zé)負(fù)載均衡猪半、緩存磨确、訪問控制乏奥、API計(jì)量和監(jiān)控

4.如果您想從微服務(wù)中受益邓了，每一個服務(wù)都應(yīng)該有自己的數(shù)據(jù)庫模式驶悟，因?yàn)樗軐?shí)現(xiàn)松耦合

C.微服務(wù)的優(yōu)點(diǎn)

1.解決了復(fù)雜問題，把可能會變得龐大的單體應(yīng)用程序分解成一套服務(wù)

2.這種架構(gòu)使得每個服務(wù)都可以由一個團(tuán)隊(duì)獨(dú)立專注開發(fā)

3.微服務(wù)架構(gòu)模式可以實(shí)現(xiàn)每一個微服務(wù)獨(dú)立部署

4.微服務(wù)架構(gòu)模式使得每個服務(wù)能夠獨(dú)立擴(kuò)展

D.微服務(wù)的缺點(diǎn)

1.微服務(wù)這個術(shù)語的重點(diǎn)過多偏向于服務(wù)的規(guī)模，有些開發(fā)者主張構(gòu)建極細(xì)粒度的10至100LOC（代碼行）服務(wù)熊响，但小型服務(wù)只是一種手段诗赌，目標(biāo)在于充分分解應(yīng)用程序以方便應(yīng)用敏捷開發(fā)和部署

2.微服務(wù)是一個分布式系統(tǒng)铭若，使得整體變得復(fù)雜叼屠，開發(fā)者需要選擇和實(shí)現(xiàn)基于消息或者RPC的進(jìn)程間通信機(jī)制镜雨，模塊間通過語言級方法/過程調(diào)用相互調(diào)用荚坞，這比單體應(yīng)用要復(fù)雜得多

3.分區(qū)數(shù)據(jù)庫架構(gòu)颓影，需要更新不同服務(wù)所用的數(shù)據(jù)庫诡挂，通常不會選擇分布式事務(wù)，不僅僅是因?yàn)镃AP定理

4.測試微服務(wù)應(yīng)用程序也很復(fù)雜吴裤，需要啟動該服務(wù)及其所依賴的所有服務(wù)麦牺，或者至少為這些服務(wù)配置存根

5.實(shí)現(xiàn)了跨越多服務(wù)變更剖膳，在微服務(wù)中需要仔細(xì)規(guī)劃和協(xié)調(diào)出現(xiàn)的變更至每個服務(wù)

6.部署基于微服務(wù)的應(yīng)用程序也是非常復(fù)雜的

7.每個服務(wù)都有多個運(yùn)行時(shí)實(shí)例吱晒，還有更多的移動部件需要配置仑濒、部署墩瞳、擴(kuò)展和監(jiān)控喉酌，還需要實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)機(jī)制泪电，使得服務(wù)能夠發(fā)現(xiàn)需要與之通信的任何其他服務(wù)的位置（主機(jī)和端口），需要開發(fā)人員能高度控制部署方式和高度自動化

二和蚪、使用API網(wǎng)關(guān)

A.客戶端與微服務(wù)直接通信

1.問題：客戶端的需求與每個微服務(wù)暴露的細(xì)粒度的API不匹配怯疤，公網(wǎng)下效率低下

2.問題：有可能使用了非web友好協(xié)議集峦，一個服務(wù)可能使用了Thrift二進(jìn)制rpc，而另一個可能使用AMQP消息協(xié)議速妖，這些對瀏覽器還是防火墻都是不友好的聪黎，最好是在內(nèi)部使用

3.缺點(diǎn)：難以重構(gòu)微服務(wù)

B.使用API網(wǎng)關(guān)

1.API網(wǎng)關(guān)是一個服務(wù)器锦秒，是系統(tǒng)的單入口點(diǎn)旅择，類似于面向?qū)ο笤O(shè)計(jì)模式中的門面（Facade）模式生真，封裝了內(nèi)部系統(tǒng)架構(gòu)铺敌，并針對每個客戶端提供一個定制API偿凭，還可用于認(rèn)證弯囊、監(jiān)控匾嘱、負(fù)載均衡霎烙、緩存和靜態(tài)響應(yīng)處理

2.API網(wǎng)關(guān)負(fù)責(zé)請求路由悬垃、組合和協(xié)議轉(zhuǎn)換尝蠕，通常會調(diào)用多個微服務(wù)和聚合結(jié)果來處理一個請求看彼，可以在Web協(xié)議（如HTTP和WebSocket）和用于內(nèi)部的非Web友好協(xié)議之間進(jìn)行轉(zhuǎn)換

3.API還可以為每個客戶端提供一個定制API，通常為客戶端暴露一個粗粒度的API

C.API網(wǎng)關(guān)的優(yōu)點(diǎn)與缺點(diǎn)

1.主要好處是它封裝了應(yīng)用程序的內(nèi)部結(jié)構(gòu)顽铸，客戶端只與網(wǎng)關(guān)通信跋破，而不必調(diào)用特定的服務(wù)

2.缺點(diǎn)是它是另一個高度可用的組件毒返，需要開發(fā)拧簸、部署和管理盆赤，API網(wǎng)關(guān)可能會成為開發(fā)瓶頸

3.重要的是更新API網(wǎng)關(guān)的過程應(yīng)盡可能地放緩一些，否則淑际，開發(fā)人員將被迫排除等待網(wǎng)關(guān)更新

D.實(shí)施API網(wǎng)關(guān)

1.在一個支持異步春缕、非阻塞I/O平臺上構(gòu)建API網(wǎng)關(guān)是很有必要的锄贼。Node.js宅荤、Nginx Plus

2.API網(wǎng)關(guān)通過簡單地把他們（請求）路由到適當(dāng)?shù)暮蠖朔?wù)來處理一些請求冯键。它通過調(diào)用多個后端服務(wù)并聚合結(jié)果來處理其他請求琼了，API網(wǎng)關(guān)應(yīng)該并發(fā)執(zhí)行獨(dú)立請求

3.使用傳統(tǒng)的異步回調(diào)方式來編寫API組合代碼會很快使您陷入回調(diào)地獄，好的方式是使用響應(yīng)式方法以聲明式編寫API網(wǎng)關(guān)代碼

4.一個基于微服務(wù)的應(yīng)用程序是一個分布式系統(tǒng)所袁，必須使用一個進(jìn)程間（inter-process）通信機(jī)制燥爷，有兩種方案：一是使用基于消息的異步機(jī)制前翎，如JMS港华、AMQP立宜、ZeroMQ等橙数；另一種采用了同步機(jī)制，如HTTP和Thrift施流；API網(wǎng)關(guān)需要支持各種通信機(jī)制

5.API網(wǎng)關(guān)需要知道與其通論的每個微服務(wù)的位置（IP地址和端口）瞪醋，需要使得系統(tǒng)的服務(wù)發(fā)現(xiàn)機(jī)制：服務(wù)端發(fā)現(xiàn)或客戶端發(fā)現(xiàn)银受，API網(wǎng)關(guān)必須能夠查詢服務(wù)注冊中心宾巍，該注冊中心是所有微服務(wù)實(shí)例及其位置的數(shù)據(jù)庫

6.當(dāng)一個服務(wù)調(diào)用另一個響應(yīng)緩慢或不可用的服務(wù)時(shí)，API網(wǎng)關(guān)不應(yīng)該無期限地等待下游服務(wù)选浑，如何處理故障問題取決于決定的方案和哪些服務(wù)發(fā)生故障

7.如果可以古徒，API網(wǎng)關(guān)還可以返回緩存數(shù)據(jù)隧膘，通過返回默認(rèn)數(shù)據(jù)或緩存數(shù)據(jù)疹吃，確保系統(tǒng)發(fā)生故障時(shí)最小程度上影響到用戶體驗(yàn)

8.Netflix Hystrix是一個非常有用的用于編寫調(diào)用遠(yuǎn)程服務(wù)代碼的庫

三萨驶、進(jìn)程間通信

A.簡介

1.服務(wù)必須通過進(jìn)程間通信（IPC）機(jī)制進(jìn)行交互

B.交互方式

1.第一類：

* 一對一判莉，每個客戶端請求都由一個服務(wù)實(shí)例處理

* 一對多券盅，每個請求由多個服務(wù)實(shí)例處理

2.第二類：

* 同步锰镀，客戶端要求服務(wù)及時(shí)響應(yīng)，在等待過程中可能會發(fā)生阻塞

* 異步咖刃，客戶端在等待響應(yīng)時(shí)不會發(fā)生阻塞泳炉，但響應(yīng)（如果有）不一事實(shí)上立即返回

3.一對一交互，包括同步（請求/響應(yīng)）與異步（通知與請求/異步響應(yīng)）：

* 請求/響應(yīng)嚎杨，客戶端向服務(wù)發(fā)出請求并等待響應(yīng)花鹅。客戶端要求響應(yīng)及時(shí)到達(dá)枫浙。在基于純種的應(yīng)用程序中，發(fā)出請求的線程可能在等待時(shí)發(fā)生阻塞

* 通知（又稱為單向請求）箩帚，客戶端向服務(wù)發(fā)送請求真友，但不要求響應(yīng)

* 請求/異步響應(yīng)，客戶端向服務(wù)發(fā)送請求紧帕，服務(wù)異步響應(yīng)盔然。客戶端在等待時(shí)不發(fā)生阻止，適用于假設(shè)響應(yīng)可能不會立即到達(dá)的場景

4.一對多交互愈案，異步類型：

* 發(fā)布/訂閱客戶端挺尾，發(fā)布通知消息，由零個或多個感興趣的服務(wù)消費(fèi)

* 發(fā)布/異步響應(yīng)刻帚，客戶端發(fā)布請求消息，之后等待一定時(shí)間來接收消費(fèi)者的響應(yīng)

C.定義API

1.無論使用何種IPC機(jī)制涩嚣，使用接口定義語言（interface definition language,IDL）來嚴(yán)格定義服務(wù)API都是非常有必要的

2.在對需要實(shí)現(xiàn)的服務(wù)API定義進(jìn)行迭代之后崇众，可以通過編寫接口定義并與客戶端開發(fā)人員進(jìn)行審閱來開始開發(fā)服務(wù)

D.演化API

1.需要逐步部署服務(wù)的新版本，以便新舊版本的服務(wù)同時(shí)運(yùn)行

2.如果使用了基于HTTP的機(jī)制（如REST）航厚，一種方法是將版本號嵌入到URL中

E.處理局部故障

1.處理局部故障的策略：

* 網(wǎng)絡(luò)超時(shí)顷歌，不要無限期地阻塞，始終使用超時(shí)方案

* 限制未完成的請求數(shù)量幔睬，對客戶端擁有特定服務(wù)的未完成請求的數(shù)量設(shè)置上限

* 斷路器模式眯漩，追蹤成功和失敗請求的數(shù)量。如果錯誤率超過配置閾值麻顶，則斷開斷路器

* 提供回退赦抖，請求失敗時(shí)執(zhí)行回退邏輯

F.IPC技術(shù)

1.基于HTTP的REST或Thrift

2.異步、基于消息的通信機(jī)制辅肾，如AMQP或STOMP

3.基于文本的格式队萤，如JSON或XML

4.使用如Avro或Protocol Buffers等二進(jìn)制格式（更加高效）

G.異步、基于消息的通信

1.客戶端通過發(fā)送消息向服務(wù)發(fā)出請求矫钓，如果服務(wù)需要回復(fù)要尔，則通過向客戶端發(fā)送一條單獨(dú)的消息來實(shí)現(xiàn)，由于通信是異步的新娜，因此客戶端不會阻塞等待回復(fù)赵辕，客戶端被假定不會立即收到回復(fù)

2.兩種通道

* 點(diǎn)對點(diǎn)通道，發(fā)送一條消息給一個確切的概龄、正在從通道讀取消息的消費(fèi)者

* 發(fā)布訂閱通道还惠，將每條消息傳遞給所有已訂閱的消費(fèi)者

3.大量的開源消息系統(tǒng)：RabbitMQ、Apache Kafka私杜、Apache ActiveMQ吸重、NSQ

4.使用消息傳遞的優(yōu)點(diǎn)：

* 將客戶端與服務(wù)分離，服務(wù)實(shí)例對客戶端而言是透明的歪今，客戶端不需要使用發(fā)現(xiàn)機(jī)制來確定服務(wù)實(shí)例的位置

* 消息緩沖嚎幸，將消息寫入通道隊(duì)列，直到消費(fèi)者處理它們

* 靈活的客戶端—服務(wù)交互

* 毫無隱瞞的進(jìn)程間通信

5.缺點(diǎn)：

* 額外的復(fù)雜操作寄猩，消息傳遞系統(tǒng)是一個需要安裝嫉晶、配置和操作的系統(tǒng)組件。消息代理必須高度可用

* 實(shí)施基于請求/響應(yīng)式交互的復(fù)雜性

H.同步的請求/響應(yīng)IPC

1.客戶端向服務(wù)器發(fā)送請求，該服務(wù)處理該請求并返回響應(yīng)

2.兩種流行協(xié)議分別是REST和Thrift

3.REST

* 資源是REST的關(guān)鍵概念替废，通常表示業(yè)務(wù)對象或業(yè)務(wù)對象的集合

* 使用HTTP動詞（謂詞）來操縱資源箍铭，通過URL引用

* REST成熟度模型：

* 級別0的API客戶端通過向其唯一的URL端點(diǎn)發(fā)送HTTP POST請求來調(diào)用該服務(wù)，每個請求都被指定要執(zhí)行的操作椎镣、操作的目標(biāo)（如業(yè)務(wù)對象）以及參數(shù)

* 級別1的API支持資源概念

* 級別2的API使用HTTP動詞（謂詞）執(zhí)行操作：GET檢索诈火、POST創(chuàng)建、PUT更新

* 級別3的API基于非常規(guī)命名原則設(shè)計(jì)状答，基本思想是GET請求返回的資源的表述冷守，包含用于執(zhí)行該資源上允許的操作的鏈接

* 使用基于HTTP的協(xié)議的好處：

* 簡單易懂

* 可以使用瀏覽器來測試 HTTP API

* 直接支持請求/響應(yīng)式通信

* 屬于防火墻友好

* 不需要中間代碼，簡化系統(tǒng)架構(gòu)

* 缺點(diǎn)：

* 僅直接支持請求/響應(yīng)的交互方式

* 因?yàn)橹苯油ㄐ啪疲员仨氃诮粨Q期間都運(yùn)行著

* 必須知道每個服務(wù)實(shí)例的位置（即URL）

4.Thrift

* 是一個用于編寫跨語言RPC客戶端和服務(wù)器skeleton拍摇，由一個或多個服務(wù)組成，定義類假于一個Java接口馆截，是強(qiáng)類型方法的集合

* 支持多種消息格式：JSON充活、二進(jìn)制和壓縮二進(jìn)制

I.消息格式

1.兩種主要的消息格式

* 文本：JSON、XML蜡娶，人類可讀混卵，自描述

* 二進(jìn)制：二進(jìn)制Thrift，Protocol Buffers和Apache Avro

四窖张、服務(wù)發(fā)現(xiàn)

A.為何使用服務(wù)發(fā)現(xiàn)

1.服務(wù)實(shí)例具有動態(tài)分配的網(wǎng)絡(luò)位置淮菠。此外，由于自動擴(kuò)縮荤堪、故障與升級合陵，整級服務(wù)實(shí)例會動態(tài)變更。因此澄阳，您的客戶端代碼需要使用更精確的服務(wù)發(fā)現(xiàn)機(jī)制

2.兩種主要的服務(wù)發(fā)現(xiàn)模式：客戶端發(fā)現(xiàn)（client-side discovery）與服務(wù)端發(fā)現(xiàn)（server-side discovery）

B.客戶端發(fā)現(xiàn)模式

1.客戶端負(fù)責(zé)確定可用服務(wù)實(shí)例的網(wǎng)絡(luò)位置和請求負(fù)載均衡拥知。客戶端查詢服務(wù)注冊中心（service registry）碎赢，它是可用服務(wù)實(shí)例的數(shù)據(jù)庫低剔，之后，客戶端利用負(fù)載均衡算法選擇一個可用的服務(wù)實(shí)例并發(fā)出請求

2.服務(wù)實(shí)例的網(wǎng)絡(luò)位置在服務(wù)注冊中心啟動時(shí)被注冊肮塞，當(dāng)實(shí)例終止時(shí)襟齿，它將從服務(wù)注冊中心移除，通常使用心跳機(jī)制周期性地刷新服務(wù)實(shí)例的注冊信息

3.優(yōu)點(diǎn)：相對簡單枕赵，可以實(shí)現(xiàn)智能的猜欺，特定于應(yīng)用程序的負(fù)載均衡決策

4.缺點(diǎn)：將客戶端與服務(wù)注冊中心耦合在一起，必須為服務(wù)客戶端使用的每種編程語言和框架實(shí)現(xiàn)客戶端服務(wù)發(fā)現(xiàn)邏輯

5.Netflix OSS提供了一個很好的客戶端發(fā)現(xiàn)模式示例拷窜，Netflix Eureka是一個服務(wù)注冊中心开皿，Netflix Ribbon是一個IPC客戶端涧黄，用于在可用服務(wù)實(shí)例之間請求負(fù)載均衡

C.服務(wù)端發(fā)現(xiàn)模式

1.客戶端通過負(fù)載均衡器向服務(wù)發(fā)出請求，負(fù)載均衡器查詢服務(wù)注冊中心并將每個請求路由到可用的服務(wù)實(shí)例赋荆，服務(wù)實(shí)例由服務(wù)注冊中心注冊與銷毀

2.AWS Elastic Load Balancer（ELB）是一個服務(wù)端發(fā)現(xiàn)路由示例

3.HTTP服務(wù)器和負(fù)載均衡器（如Nginx Plus和Nginx）也可以作為服務(wù)端發(fā)現(xiàn)負(fù)載均衡器

4.優(yōu)點(diǎn)：把發(fā)現(xiàn)的細(xì)節(jié)從客戶端抽象出來笋妥，消除了為服務(wù)客戶端使用的每種編程語言和框架都實(shí)現(xiàn)發(fā)現(xiàn)邏輯的必要性

5.缺點(diǎn)：除非負(fù)載均衡器由部署環(huán)境提供，否則您需要引入這個高可用系統(tǒng)組件窄潭，并進(jìn)行設(shè)置和管理

D.服務(wù)注冊中心

1.服務(wù)注冊中心（service registry）是服務(wù)發(fā)現(xiàn)的一個關(guān)鍵部分春宣，是一個包含了服務(wù)實(shí)例網(wǎng)絡(luò)位置的數(shù)據(jù)庫。服務(wù)注冊中心由使用了復(fù)制協(xié)議（replication protocol）來維護(hù)一致性的服務(wù)器集群組成

2.Netflix Eureka嫉你、etcd月帝、Consul、Apache ZooKeeper

E.服務(wù)注冊方式

1.服務(wù)實(shí)例自我注冊均抽，即自注冊模式

2.使用其他系統(tǒng)組件來管理服務(wù)實(shí)例的注冊嫁赏，即第三方注冊模式

F.自注冊模式

1.服務(wù)實(shí)例負(fù)責(zé)在服務(wù)注冊中心注冊和注銷自己其掂。如果有必要油挥，服務(wù)實(shí)例通過發(fā)送心跳請求來防止其注冊信息過期

2.好處是相對簡單，不需要任何其他系統(tǒng)組件款熬，缺點(diǎn)是它將服務(wù)實(shí)例與服務(wù)注冊中心耦合

G.第三方注冊模式

1.服務(wù)實(shí)例不負(fù)責(zé)再向服務(wù)注冊中心注冊自己深寥，該工作將由被稱為服務(wù)注冊器（service register）的另一系統(tǒng)組件負(fù)責(zé)

2.服務(wù)注冊器通過輪詢部署環(huán)境或訂閱事件來跟蹤運(yùn)行實(shí)例集的變更情況

3.好處是服務(wù)與服務(wù)注冊中心之間解耦，缺點(diǎn)是除非部署環(huán)境內(nèi)置贤牛，否則同樣需要引入這樣一個高可用系統(tǒng)組件惋鹅，并進(jìn)行設(shè)置和管理

五、事件驅(qū)動數(shù)據(jù)管理

A.微服務(wù)和分布式數(shù)據(jù)管理問題

1.使用關(guān)系型數(shù)據(jù)庫的一個主要優(yōu)點(diǎn)是應(yīng)用程序可以使用ACID事務(wù)殉簸，另一大好處是它提供了SQL語言

2.每個微服務(wù)所擁有的數(shù)據(jù)對當(dāng)前微服務(wù)來說是私有的闰集，只能通過其提供的API進(jìn)行訪問

3.一個分區(qū)的數(shù)據(jù)存儲混合持久化架構(gòu)具有許多優(yōu)點(diǎn)，包括了松耦合的服務(wù)以及更好的性能與可擴(kuò)展性

B.事件驅(qū)動架構(gòu)

1.微服務(wù)在發(fā)生某些重要事件時(shí)發(fā)布一個事件般卑，其他微服務(wù)訂閱了這些事件武鲁，當(dāng)微服務(wù)接收到一個事件時(shí)，它可以更新自己的業(yè)務(wù)實(shí)體

2.可以使用事件實(shí)現(xiàn)跨多服務(wù)的業(yè)務(wù)事務(wù)

3.優(yōu)點(diǎn)：能夠?qū)崿F(xiàn)跨越多服務(wù)并提供最終一致性事務(wù)蝠检，使得應(yīng)用程序能夠維護(hù)物化視圖

4.缺點(diǎn)：其編程模型比使用ACID事務(wù)更復(fù)雜沐鼠，訂閱者必須要檢測和忽略重復(fù)的事件

C.實(shí)現(xiàn)原子性

1.標(biāo)準(zhǔn)方法是使用涉及到數(shù)據(jù)庫和Message Broker的分布式事務(wù)

D.使用本地事務(wù)發(fā)布事件

1.應(yīng)用程序使用僅涉及本地事務(wù)的多步驟過程來發(fā)布事件，訣竅在于存儲業(yè)務(wù)實(shí)體狀態(tài)的數(shù)據(jù)庫中有一個用作消息隊(duì)列的EVENT表

2.好處是保證了被發(fā)布的事件每次更新都不依賴于2PC叹谁，事件可以消除推斷的需要

3.缺點(diǎn)是很容易出錯

E.挖掘數(shù)據(jù)庫事務(wù)日志

1.使用線程或進(jìn)程發(fā)布事件饲梭，該進(jìn)程或線程對數(shù)據(jù)庫的事務(wù)或者提交日志進(jìn)行挖掘，當(dāng)更新數(shù)據(jù)庫時(shí)焰檩，更改信息被記錄到數(shù)據(jù)庫的事務(wù)日志中憔涉，Transaction Log Miner線程或進(jìn)程讀取事務(wù)日志并向Message Broker發(fā)布事件

2.好處是它能保證被發(fā)布的事件每次更新都不依賴于2PC，可以通過將事件發(fā)布與應(yīng)用程序的業(yè)務(wù)邏輯分離來簡化應(yīng)用程序

3.缺點(diǎn)是事務(wù)日志的格式對于每個數(shù)據(jù)庫來說都是專有的析苫，記錄于事務(wù)日志中的低級別更新可能難以對高級業(yè)務(wù)事件進(jìn)行逆向工程

F.使用事件溯源

1.事件溯源通過使用完全不同的监氢、不間斷的方式來持久化業(yè)務(wù)實(shí)體布蔗，實(shí)現(xiàn)無2PC原子性。應(yīng)用程序不存儲實(shí)體的當(dāng)前狀態(tài)浪腐，而是存儲一系列狀態(tài)改變事件纵揍。通過無回放事件來重建實(shí)體當(dāng)前狀態(tài)。由于保存事件是一個單一操作议街，因此具有原子性

2.事件被持久化在事件存儲中泽谨，事件存儲是一個事件數(shù)據(jù)庫，該存儲有一個用于添加和檢索實(shí)體事件的API

3.好處：可以在狀態(tài)發(fā)生變化時(shí)可靠地發(fā)布事件特漩，解決了數(shù)據(jù)一致性吧雹；持久化的是事件而不是領(lǐng)域?qū)ο螅苊饬藢ο箨P(guān)系阻抗失配問題涂身；提供對業(yè)務(wù)實(shí)體所做更改的100%可靠的審計(jì)日志雄卷；業(yè)務(wù)邏輯包括松耦合的交換事件業(yè)務(wù)實(shí)體，從單體應(yīng)用程序遷移到微服務(wù)架構(gòu)更加容易

4.缺點(diǎn)：是一種不同而陌生的編程風(fēng)格蛤售，存在學(xué)習(xí)曲線丁鹉；事件存儲僅支持通過主鍵查找業(yè)務(wù)實(shí)體；必須使用命令查詢責(zé)任分離（CQRS）來實(shí)現(xiàn)查詢悴能，應(yīng)用程序必須處理最終一致的數(shù)據(jù)

六揣钦、選擇部署策略

A.動機(jī)

1.微服務(wù)應(yīng)用程序由數(shù)十甚至上百個服務(wù)組成，服務(wù)以不同的語言和框架編寫漠酿，每個都是一個迷你的應(yīng)用程序冯凹，需要根據(jù)該服務(wù)的需求運(yùn)行每個服務(wù)的一定數(shù)量的實(shí)例，必須為每個服務(wù)實(shí)例提供相應(yīng)的CPU炒嘲、內(nèi)存和I/O資源

B.單主機(jī)多服務(wù)實(shí)例模式

1.單主機(jī)多服務(wù)實(shí)例（Multiple Service Instances per Host）模式宇姚，可以提供一個或多個物理主機(jī)或虛擬主機(jī)，并在每個上運(yùn)行多個服務(wù)實(shí)例夫凸，每個服務(wù)實(shí)例在一個或多個主機(jī)的標(biāo)準(zhǔn)端口上運(yùn)行

2.一種變體是每個服務(wù)實(shí)例都是一個進(jìn)程或進(jìn)程組

3.另一個變體是在同一進(jìn)程或進(jìn)程組中運(yùn)行多個服務(wù)實(shí)例

4.優(yōu)點(diǎn)：資源使用率相對較高浑劳，多個服務(wù)實(shí)例共享服務(wù)器及其操作系統(tǒng)。如果進(jìn)程或進(jìn)程組運(yùn)行了多個服務(wù)實(shí)例寸痢，則效率更高呀洲；部署服務(wù)實(shí)例相對較快；由于缺乏開銷啼止，通常啟動一個服務(wù)是非车蓝海快的

5.缺點(diǎn)：服務(wù)實(shí)例很少或者沒有隔離，除非每個服務(wù)實(shí)例是一個單獨(dú)的進(jìn)程献烦，一個行為不當(dāng)?shù)姆?wù)實(shí)例可能會占用掉主機(jī)的所有內(nèi)存或CPU滓窍；部署服務(wù)的運(yùn)維團(tuán)隊(duì)必須了解執(zhí)行此操作的具體細(xì)節(jié)

C.每個主機(jī)一個服務(wù)實(shí)例模式

1.每個主機(jī)一個服務(wù)實(shí)例（Service Instance per Host）模式，在主機(jī)上單獨(dú)運(yùn)行每個服務(wù)實(shí)例巩那，每個虛擬機(jī)一個服務(wù)實(shí)例模式和每個容器一個服務(wù)實(shí)例模式

2.每個虛擬機(jī)一個服務(wù)實(shí)例模式吏夯，將每個服務(wù)打包為一個虛擬機(jī)（VM）鏡像此蜈，每個服務(wù)實(shí)例都是一個使用該VM鏡像啟動的VM

3.每個虛擬機(jī)一個服務(wù)實(shí)例模式的優(yōu)點(diǎn)：每個服務(wù)實(shí)例運(yùn)行是完全隔離的；可以利用成熟的云基礎(chǔ)架構(gòu)噪生；封裝了服務(wù)的實(shí)現(xiàn)技術(shù)裆赵；

4.每個虛擬機(jī)一個服務(wù)實(shí)例模式的缺點(diǎn)：資源利用率較低；公共IaaS中的VM通常是收費(fèi)的跺嗽，無論他們是處于繁忙還是空閑战授；部署新版本的服務(wù)時(shí)通常很慢；要對很多未劃分的重?fù)?dān)負(fù)責(zé)桨嫁；

5.每個容器一個服務(wù)實(shí)例（Service Instance per Container）模式植兰，每個服務(wù)實(shí)例都在其自己的容器中運(yùn)行（Docker）

6.容器模式的優(yōu)點(diǎn)：將服務(wù)實(shí)例彼此隔離，輕松監(jiān)控每個容器所消耗的資源璃吧，封裝了服務(wù)實(shí)現(xiàn)技術(shù)楣导，容器管理API作為管理服務(wù)的API；容器是輕量級技術(shù)畜挨，可以快速構(gòu)建筒繁，也可以很快地啟動；

7.容器模式的缺點(diǎn)：不成熟朦促，不像VM那樣安全膝晾，因?yàn)楣蚕砹酥鳈C(jī)的OS內(nèi)核栓始；需要負(fù)責(zé)劃分容器鏡像管理重?fù)?dān)务冕；通常部署在一個按單個VM收費(fèi)的基礎(chǔ)設(shè)施上，可能會產(chǎn)生超額配置VM的額外成本幻赚，以處理負(fù)載峰值禀忆；

D.Serverless部署

1.AWS Lambda

七、重構(gòu)單體為微服務(wù)

A.微服務(wù)重構(gòu)概述

1.一個不要使用的策略是“大爆炸”重寫落恼，就是您將所有的開發(fā)工作都集中在從頭開始構(gòu)建新的基于微服務(wù)的應(yīng)用程序

2.應(yīng)該逐步重構(gòu)單體應(yīng)用程序箩退，逐漸添加新功能，并以微服務(wù)的形式創(chuàng)建現(xiàn)有功能的擴(kuò)展——以互補(bǔ)的形式修改單體應(yīng)用佳谦，并且一同運(yùn)行微服務(wù)和修改后的單體

B.策略一：停止挖掘

1.洞穴定律：當(dāng)你身處在一個洞穴中戴涝，你應(yīng)該停止挖掘

2.當(dāng)你的單體應(yīng)用變得難以管理時(shí)，應(yīng)該停止擴(kuò)張钻蔑，避免使單體變得更大

3.三種策略來訪問單體數(shù)據(jù)：

* 調(diào)用由單體提供的遠(yuǎn)程API

* 直接訪問單體數(shù)據(jù)庫

* 維護(hù)自己的數(shù)據(jù)副本啥刻，與單體數(shù)據(jù)庫同步

4.粘合代碼，將服務(wù)與單體集成咪笑，位于單體可帽、服務(wù)或兩者中的粘合代碼負(fù)責(zé)數(shù)據(jù)集成，有時(shí)被稱為防護(hù)層（anti-corruption layer）窗怒，因?yàn)檎澈洗a阻止了服務(wù)被遺留的單體領(lǐng)域模型的概念污染映跟，這些服務(wù)具有自己的原始領(lǐng)域模式

C.策略二：前后端分離

1.縮小單體應(yīng)用的一個策略是從業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層拆分出表現(xiàn)層：

* 表現(xiàn)層（Presentation Layer,PL）處理HTTP請求并實(shí)現(xiàn)（REST） API或基于HTML的WebUI組件蓄拣，通常存在大量代碼

* 業(yè)務(wù)邏輯層（Business Logic Layer,BLL）作為應(yīng)用程序核心，實(shí)現(xiàn)業(yè)務(wù)規(guī)則的組件

* 數(shù)據(jù)訪問層（Data Access Layer,DAL）訪問基礎(chǔ)架構(gòu)組件的組件努隙，如數(shù)據(jù)庫和消息代理

2.業(yè)務(wù)層具有由一個或多個門面組成的粗粒度API球恤，其封裝了業(yè)務(wù)邏輯組件。一個應(yīng)用程序包含表現(xiàn)層荸镊，另一個應(yīng)用程序包含業(yè)務(wù)和數(shù)據(jù)訪問邏輯

3.優(yōu)點(diǎn)：使您能夠獨(dú)立于彼此開發(fā)碎捺、部署和擴(kuò)展這兩個應(yīng)用，允許表現(xiàn)層開發(fā)人員在用戶界面上快速迭代贷洲，可以輕松執(zhí)行A/B測試收厨；暴露了可以被您開發(fā)的微服務(wù)調(diào)用的遠(yuǎn)程API

4.只是一個局部解決方案，兩個應(yīng)該程序中的一個或兩個很可能是一個無法管理的單體优构，需要使用第三種策略來消除剩余的整體或單體

D.策略三：提取服務(wù)

1.將龐大的現(xiàn)有模塊轉(zhuǎn)變?yōu)楠?dú)立的微服務(wù)诵叁，每次提取一個模塊并將其轉(zhuǎn)換成服務(wù)時(shí)，單體就會縮小

2.從容易提取的幾個模塊開始钦椭，將得到微服務(wù)的相關(guān)經(jīng)驗(yàn)拧额，之后提取能給你最大利益的模塊；提取頻繁更改的模塊通常是有益的彪腔；提取與單體的其他模塊有顯著不同的模塊也是有益的侥锦；

3.提取模塊第一步是在模塊和單體之間定義一個粗粒度接口；一旦實(shí)現(xiàn)了粗粒度接口德挣，就可以將模塊變成獨(dú)立的服務(wù)恭垦，必須編寫代碼以使單體和服務(wù)通過使用進(jìn)程間通信（IPC）機(jī)制的API進(jìn)行通信；第二個重構(gòu)步驟是將模塊轉(zhuǎn)換為一個獨(dú)立服務(wù)格嗅；

https://pan.baidu.com/s/1o9i6Ats

ee16