2-2 架構(gòu)設(shè)計(jì)過程
一、架構(gòu)風(fēng)格與架構(gòu)模式
- 架構(gòu)風(fēng)格（Architectural styles）有哪些
根據(jù)不同緯度有不同的分類方式，分類比較多。
- component-based 基于組件（可復(fù)用）
- Monolithic application整體應(yīng)用
- Layered 分層架構(gòu)
- Pipes and filters 管道與過濾器（部分分布式鎖或者分布式事務(wù)的實(shí)現(xiàn)）
- Event-drivens 時(shí)間驅(qū)動(dòng)（消息隊(duì)列的實(shí)現(xiàn)）
- Plug-ins 插件化 （做插件的，外部業(yè)務(wù)經(jīng)常變化，做好底層保持不變，表示層應(yīng)對(duì)不同變化使用插件化的方式去做）
- Client-Service 客戶服務(wù)端（安卓、iOS）
- service-oriente 面向服務(wù)
- 架構(gòu)模式（Architectural Pattern）
- 多層架構(gòu)
- MVC
- DDD
...
二、六大主流架構(gòu)風(fēng)格介紹
-
，水平切分服務(wù)
業(yè)務(wù)（產(chǎn)品）- 前段 - 后端 - DB -測試 -運(yùn)維
gateway -> controller -> service -> dao
...
：
- 軟件架構(gòu)影響企業(yè)組織架構(gòu)，如果不能改變企業(yè)組織架構(gòu)就要考慮迎合企業(yè)組織架構(gòu)進(jìn)行軟件架構(gòu)設(shè)計(jì)。
- DDD的戰(zhàn)略設(shè)計(jì)中Bounded context 按部門拆分。
DDD、core/composite/api
詳見：A2-05.02.六大架構(gòu)風(fēng)格介紹11:55
事件驅(qū)動(dòng)的三個(gè)關(guān)鍵組件：生產(chǎn)者、路由器、消費(fèi)者
時(shí)間驅(qū)動(dòng)的方式可以實(shí)現(xiàn)絕對(duì)的解耦
事件是狀態(tài)的更改和更新，例如：
a. 將商品放入購物車。
b. 購買商品。
c. 修改價(jià)格或者收貨地址。
d. 狀態(tài)更新：訂單發(fā)貨的通知。
基于事件驅(qū)動(dòng)架構(gòu)的實(shí)現(xiàn)：
Kafka\RocketMQ\RabbitMQ\ActiveMQ\Spring AMQP\分布式事務(wù)saga
例如：core system 結(jié)合plug-ins的實(shí)現(xiàn)
基于微內(nèi)核架構(gòu)的實(shí)現(xiàn)：操作系統(tǒng)
，垂直切分服務(wù)
微服務(wù)本身就是基于服務(wù)的架構(gòu)
延伸：查一查微服務(wù)面試題
，解決可伸縮性和并發(fā)性問題
基于空間的架構(gòu)的實(shí)現(xiàn)：K8s
三、軟件非功能性需求
架構(gòu)的非功能性參數(shù)
1、性能/Preformance：包括壓力測試、峰值分析、使用功能頻率、所需容量和響應(yīng)時(shí)間的分析
衡量指標(biāo)：時(shí)間（QPS、響應(yīng)時(shí)間、延遲）
2、可擴(kuò)展性/Scalability：隨著用戶和請(qǐng)求數(shù)量的增加，系統(tǒng)執(zhí)行和操作的能力
衡量指標(biāo)：空間（加機(jī)器加內(nèi)存cpu、水平擴(kuò)展、垂直擴(kuò)展）
注：一般微服務(wù)都是水平擴(kuò)展，加機(jī)器重新部署服務(wù)，而不是將服務(wù)的cpu內(nèi)存調(diào)大
3、可用性/Availability：對(duì)于不停機(jī)系統(tǒng)，可用性指標(biāo)指故障率（比如99.99%）
衡量指標(biāo)：時(shí)間導(dǎo)數(shù)/可用率（正常時(shí)間/總時(shí)間）
如何提高可用性：分布式、異地災(zāi)備...
4、安全性/Security：評(píng)估系統(tǒng)是否需要故障安全，或者安全性對(duì)系統(tǒng)的影響
衡量指標(biāo)：錢/ROI（成本收益）投入產(chǎn)出比
安全最應(yīng)該防備公司內(nèi)部，內(nèi)部能很快提升ROI（比如定期備份，內(nèi)部權(quán)限控制...）
5、可部署性/Deployability：系統(tǒng)的部署難易程度
難于衡量，那決策時(shí)用前置變量
什么因素影響可部署性最大？
架構(gòu)的選擇：默認(rèn)選擇微服務(wù)架構(gòu)
提升服務(wù)的可部署性：devops，注：devops要結(jié)合自動(dòng)化測試autotest
6、可測試性/Testability：指軟件發(fā)現(xiàn)故障并隔離定位其故障的能力特性，以及在一定時(shí)間或成本前提下進(jìn)行測試設(shè)計(jì)、測試執(zhí)行的能力
7、靈活性/Modifiability：系統(tǒng)發(fā)生功能或者其他變更的適應(yīng)能力
8、開發(fā)性/Developability ：開發(fā)的難易程度
四、單體架構(gòu)的微服務(wù)改造過程
1、微服務(wù)時(shí)如何成為主流的
繼承了單體架構(gòu)的優(yōu)勢，從能使用個(gè)人開發(fā)到大規(guī)模團(tuán)隊(duì)開發(fā)，然后逐步具備主流優(yōu)勢，最終形成規(guī)模效益
2、改造過程
參考《Microservices Patterns》 FTGO點(diǎn)餐項(xiàng)目
問：單體模式最大問題是什么？
答：開發(fā)效率低（并非并發(fā)達(dá)不到），（可開發(fā)性，可部署性，可測試性）
源碼管理，代碼沖突，測試效率低，部署效率低
目標(biāo)：能將大團(tuán)隊(duì)拆分成小團(tuán)隊(duì)
- 微服務(wù)改造第一步
1). 消息隊(duì)列、注冊(cè)中心、緩存等引入，通訊協(xié)議確定。
2). 同一數(shù)據(jù)庫下模塊拆分
3). 代碼庫的拆分（拆分代碼放在不同的git庫中，保證彼此不影響）
4). 數(shù)據(jù)庫拆分
5). 提升其他非功能性需求（可測試性，可部署性，安全性等）- 微服務(wù)拆分第二步
1). 使用DDD對(duì)服務(wù)模塊進(jìn)行拆分（目的：對(duì)服務(wù)進(jìn)行拆分，但使用同一個(gè)repository）
2). 使用CQRS進(jìn)行讀寫分離- 微服務(wù)拆分第三步
按業(yè)務(wù)線拆分代碼庫- 使用saga拆分?jǐn)?shù)據(jù)庫（前置條件：服務(wù)和代碼庫拆分完成）
1).先在一個(gè)庫中對(duì)表進(jìn)行虛擬劃區(qū)，各自區(qū)的服務(wù)獨(dú)立通過rpc調(diào)用
此步關(guān)鍵- 業(yè)務(wù)邏輯建模，使用新數(shù)據(jù)庫重構(gòu)業(yè)務(wù)邏輯代碼
- 提升其他非功能性需求（可測試性，可部署性，安全性等）
1).自動(dòng)化測試引入
2). 使用DDD可替換orderRepository
3).可配置性：配置中心
4).可監(jiān)控性：健康檢查與監(jiān)控告警
5).容器化與容器編排
