微服務架構學習精要（一）

• 2019 年 10 月 6 日
• 筆記

一、架構師、技術專家區別

架構師關注知識的廣度，而技術專家偏向某一個專業領域的深度。如果我們想成為一名架構師，那麼不應該把所有的精力都投入在某個技術領域而是需要分散關注面，在眾多領域都要有一定的深度。其次，架構師除了具備技術硬技能，還需要在溝通、組織、學習等技能做好發展。因為沒有好的軟實力，架構師則無法將自己的架構順利移交程序，並指導他們落地。

架構師的職責是什麼：制定規範+指導落地。就好像兩條腿走路，左腿向前制定規範，右腿關注落地實施。

二、軟件架構的演進

1、沒有架構

早期的系統沒有分層，所有界面、邏輯都混在一起，對於小型業務系統效率較高。但隨着業務系統的擴展，可維護性很差。

2、基於MVC的分層架構

為便於同一個公司的業務開展，將程序架構分為了界面、控制、模型層。界面負責展現、控制層貫穿整個業務流程、模型主要是業務邏輯、數據邏輯。如在java中，曾經著名的SSH架構，Struts主要是界面、Hibernats主要是模型，Spring主要是控制層。

3、面向服務的SOA

將服務分拆為多個模塊，中間有服務中間件，如IBM Websphere。臃腫的中間件，造成了效率下降、成本的上升。

4、更加拆分的微服務架構

為解決SOA的極端中心化、服務拆分顆粒度仍比較大的問題，以Docker的輕量化的技術加速了微服務的推廣。

三、微服務與SOA的本質區別

微服務一向被認為是雲中心化，但下圖微服務的架構中，仍然有註冊中心等中心組件。實際，微服務強調去帶業務的中心，而非技術中心。例如，兩業務模塊通信不再通過SOA的複雜路由、數據轉發。

四、如何進行微服務治理

1、梳理業務流程。業務需求是一切技術的根源，了解真實的業務流程，並將其疏理成為業務流程圖。對於業務的疏理花再多的時間，也是值得的。

2、抽取公共服務模塊。例如將用戶管理、短訊發送等所有業務都需要的模塊首先抽取出來，作為公共的微服務模塊。

3、定義業務服務。初期我們可以將業務服務的模塊定義得大一些，後期再進行逐步的細分。業務模塊應保障功能的相對獨立，避免過多的模塊間業務通信。

4、設計數據模型。也就是定義數據庫的表結構、相互表之間的邏輯關係。該步驟如果設計不合理，後期的改造成本非常高。

5、定義微服務的接口。也就是相互間通信的共同語言。如用戶微服務模塊應有查詢、註冊、改密碼等功能。同時建議接口API名應全局唯一，並帶上版本號。這樣便於後期註冊中心的統一管理。

五、微服務部署架構

1、當開發代碼、配置文件完成後，通過Docker鏡像的封裝，放入鏡像倉庫中。

2、當服務啟動時，由部署中心根據業務負載、業務需求下發服務容器的加載。

3、服務容器啟動完成後，將向註冊中心註冊服務。

六、微服務運行架構

1、當用戶通過app、web調用微服務時，首次將通過「調用中心」，調用中心通過註冊中心查詢服務所在的ip、port。

2、隨後調用中心將信息返回給用戶，用戶直接與調度中心進行反向代理的信息交互。微服務強調雲中心化，調用中心參與業務越少越好。

3、服務容器在運行過程中，將運行日誌寫入日誌中心，將彼此服務間的調用寫入追蹤中心，通過各中心的數據分析、記錄作為後期的分析、優化依據。