3.1、淘寶平臺“服務化”歷程

大約2007年，淘寶500人團隊，維護一個war包，200多個功能模組。

1）專案團隊協同成本高，業務響應越來越慢

2）應用複雜度超出人的認知負載。

3）錯誤難於隔離【同一個環境，一個jvm】

4）資料庫連線能力很難擴充套件：每一個機器只有10個，但是應用機器過於多，也達到了5000多連線

5）應用擴充套件成本高

2007年10月，開始進行基於SOA理念新一代服務化框架研發以及採用業務模組逐步遷移的方式進行應用架構的改造。在未來的14個月中將單一應用模式改造成基於SOA理念的分散式服務架構。在應用部署上，由之前一個幾百兆的war包部署模式改造成上百個war包獨立部署的服務化框架。結果是：

降低不同模組開發團隊間的協同成本，業務響應更迅捷。

大大降低系統間的耦合度以及整體複雜度，各個開發團隊可專注各自的業務模組。

避免了個別模組的錯誤給整體帶來的影響。

業務拆分後解放了對單資料庫叢集連線數能力的依賴。

做到針對性的業務能力擴容，減少不必要的資源浪費。

3.2、中心化 與 去中心化 服務框架的對比

SOA主要特性：

面向服務的分散式計算

服務間鬆散耦合

支援服務的組裝

服務註冊和自動發現。

以服務契約方式定義服務互動方式

傳統的SOA是以基於ESB匯流排方式，而網際網路是以去中心化服務框架。

1）ESB模式的中心化服務框架的根本訴求

　　實現異構系統之間的互動

2）去中心化分散式服務架構解決的問題

　　一般是執行在企業內部網路，基於統一的技術介面標準，網路協議，規範進行互動，已使服務的互動效率最高。

對比

1.服務呼叫方式的不同帶來業務的響應和擴充套件成本。

　　每一次的互動過程：服務呼叫者→ESB（接收服務請求）→服務提供者（服務處理）→ESB（服務提供者返回結果）→服務呼叫者（服務返回）

　　經過服務匯流排路由過的服務互動，共出現4次網路回話建立和資料傳輸，而去中心化服務框架中服務互動，一次服務的呼叫只有兩次網路會話建立和資料傳輸，在網路上的開銷減少了一半。

2.雪崩效應束縛了中心化服務框架的擴充套件能力

3.3、分散式服務框架HSF、Dubbo

HSF服務框架包含以下主要元件：

服務提供者，在服務框架中真正提供服務功能實現的應用例項，一般是叢集部署，每一個HSF的應用均是以war包形式存在，執行在阿里優化定製的tomcat容器中，在tomcat容器層集成了HSF服務框架對服務提供者或者服務呼叫者進行配置服務容器發現、服務註冊、訂閱、失效轉移等相關功能。只需配置即可，無需引入jar依賴包。

服務呼叫者，同服務提供者類似。

地址伺服器，在HSF服務框架中肩負著給服務提供者和服務呼叫者提供部署環境中所有配置伺服器和DIamond伺服器的伺服器列表資訊。是由Nginx提供該能力。再部署HSF服務環境時，會將整個環境中的配置伺服器叢集（伺服器IP列表）和Diamond伺服器叢集資訊設定在地址伺服器上，在實際生產部署中，也會部署多臺地址伺服器提供負載均衡和高可用性的服務，服務提供者會通過統一域名的方式訪問這些地址伺服器，通過DNS輪詢，實現地址伺服器訪問的高可用。

配置伺服器，配置伺服器主要負責記錄環境內所有服務釋出（服務提供者的IP地址和服務埠資訊）和服務訂閱（服務呼叫者的IP地址和服務埠資訊）資訊，並將服務相關資訊推送到服務節點上。為了追求服務釋出和訂閱推送效率，所有的服務釋出和訂閱資訊均是儲存在記憶體中。

Diamond伺服器。是一個通用的統一配置管理服務（類似zookeeper）給應用提供統一的配置設定和推送服務。

HSF優點：

1、採用Netty+Hession資料序列化協議實現服務互動

2、容錯機制

3、線性擴充套件支援，啟動容器後自動註冊

3.4、關於微服務

1.1、Martin Fowler描述：

1、分散式服務組成的系統

2、按照業務而不是技術劃分組織

3、做有生命的產品而不是專案

4、智慧化服務端點與傻瓜式服務編排

5、自動化運維

6、系統容錯

7、服務快速演化

1.2、微服務面對的問題

1、微服務化的應用架構如何進行有效的服務管控

2、分散式事務難題

3、自動化運維和平臺穩定性

1.3、微服務要求

1、服務設計：服務邊界的劃分一定是從業務的維度。

　　以什麼樣的服務顆粒定義服務。以什麼樣資料模型支撐服務能力的線性擴充套件？如何保持設計出的服務具有很好的業務前瞻性？在滿足業務需求下，服務能力的通用性？其他業務接入的擴充套件能力？

2、原有組織架構是否滿足微服務架構持續發展的需要。