Android系統架構之微服務架構

前段時間我們翻譯的《軟件架構模式》( 完整書籍的在線閱讀地址 ) 對外發布之后得到了大家的一致好評，書中講述了五種經典、流行的軟件架構模式，同時分析了五種模式的實現、優缺點等，為我們的開發工作提供了很有價值的指 導。但是《軟件架構模式》的問題在于沒有結合具體的示例來讓這些理論知識更易于吸收，因此有些同學在我的開發群反饋: 書看起來是挺好的，但是沒有具體的示例感覺看得迷迷糊糊的。因此在下打算寫一些結合Android源碼或者開發的文章來更深入的講述這些架構模式，理論與 實踐相結合，讓大家更深刻、更具體的學習到這些架構的魅力所在。

一、微服務架構模式

由于微服務架構模式的高度靈活性、伸縮性等因特性，近年來在業內發展迅猛。但由于這個架構模式仍然在不斷的發展中，業內人士對這個模式也存在很多困 惑，例如這個模式是關于什么的？它是如何實現的？本文首先為講述這個模式的關鍵概念、基礎知識以及這個架構模式的優缺點，因為只有在對它有深入的了解之后 你才能根據情況來判斷你的應用是否適合這種架構。

1.1 模式描述

不管你選擇哪種拓撲或實現風格,有幾種常見的核心概念適用于一般架構模式。第一個概念是獨立部署單元。如圖4-1所示，微服務架構的每個組件都作為一個獨立單元進行部署，讓每個單元可以通過有效、簡化的傳輸管道進行通信，同時它還有很強的擴展性，應用和組件之間高度解耦，使得部署更為簡單。

也許要理解這種模式，最重要的概念就是服務組件（service component）。不要考慮微服務架構內部的服務，最好是考慮服務組件，從粒度上講它可以小到單一的模塊，或者大至一個應用程序。服務組件包含一個或 多個模塊（如Java類），這些模塊可以提供一個單一功能，例如為特定的城市或城鎮提供天氣情況，或也可以作為一個大型商業應用的一個獨立部分，例如股票 交易布局或測定汽車保險的費率。在微服務架構中，正確設計服務組件的粒度也是一個很大的挑戰。在接下來的服務組件部分對這一挑戰進行了詳細的討論。

微服務架構模式的另一個關鍵概念是它是一個分布式的架構，這意味著架構內部的所有組件之間是完全解耦的，并通過某種遠程訪問協議（例如， JMS, AMQP, REST, SOAP, RMI等）進行訪問。這種架構的分布式特性是它實現一些優越的可擴展性和部署特性的關鍵所在。

微服務架構另一個令人興奮的特性是它是由其他常見架構模式存在的問題演化來的，而不是作為一個解決方案被創造出來等待問題出現。微服務架構的演化有兩個主要來源：使用分層架構模式的單體應用和使用面向服務架構的分布式應用。

提示 : 單體應用, 即一個應用就是一個整體。

</blockquote>

從單體應用到微服務的發展過程主要是由持續交付開發促成的。單體應用通常是由緊耦合的組件組成，這些組件同時又是另一個單一可部署單元的一部分，這 使得它繁瑣，難以改變、測試和部署應用。這些因素通常會導致應用變得脆弱，以至于每次有一點新功能部署后，如果由于這些新功能引發了異常，那么整個應用就 不能運行。微服務架構模式通過將應用分隔成多個可部署的單元（服務組件）的方法來解決這一問題，這些服務組件可以獨立于其他服務組件進行單獨開發、測試和 部署。

另一個導致微服務架構模式產生的演化過程是由面向服務架構模式（SOA）應用程序存在的問題引起的。雖然SOA模式非常強大，提供了無與倫比的抽象 級別、異構連接、服務調度，并保證通過IT能力調整業務目標，但它仍然是復雜的、昂貴的,它很難理解和實現，對大多數應用程序來說它過于重量級。微服務架 構通過簡化服務概念，消除調度需求、簡化服務組件連接和訪問來解決復雜度問題。

1.2 模式拓撲

雖然有很多方法來實現微服務架構模式,但三個主要的拓撲結構脫穎而出，最常見和流行的有:基于REST API的拓撲結構,基于REST的應用拓撲結構和集中式消息拓撲結構。

• 基于REST的API拓撲
  基于REST的API拓撲適用于網站，通過某些API對外提供小型的、自包含的服務。這種拓撲結構,如圖4 – 2所示,由粒度非常細的服務組件（因此得名微服務）組成，這些服務組件包含一個或兩個模塊并獨立于其他服務來執行特定業務功能。在這種拓結構撲中,這些細 粒度的服務組件通常被REST-based的接口訪問，而這個接口是通過一個單獨部署的web API層實現的。這種拓撲的例子包含一些常見的專用的、基于云的RESTful web service，大型網站像Yahoo, Google, and Amazon都在使用。
</ul>


圖 4-2

• 基于REST的應用拓撲結構
  基于REST的應用拓撲結構與基于REST API有所不同，它通過傳統的基于web的應用或者客戶端應用來接收客戶端請求，而不是通過一個簡單的API層。如圖4-3所示，應用的UI層是一個 web應用，可以通過簡單的基于REST的接口訪問單獨部署的服務組件。該拓撲結構中的服務組件與基于REST API拓撲結構中的不同，這些服務組件往往會更大、粒度更粗、代表整個業務應用程序的一小部分，而不是細粒度的、單一操作的服務。這種拓撲結構常見于中小 型企業等復程度相對較低的應用程序。
</ul>


圖 4-3

• 集中式消息拓撲
  微服務架構模式中另一個常見的方法是集中式消息拓撲，如圖4-4所示。該拓撲與前面提到的基于REST的應用拓撲類似，不同的是基于REST的應用拓撲結 構使用REST進行遠程訪問，而該拓撲結構則使用一個輕量級的集中式消息中間件（如，ActiveMQ, HornetQ等等）。不要將該拓撲與面向服務的架構模式混淆或將其當做SOA簡化版，這點是極其重要的。該拓撲中的輕量級消息中間件 （Lightweight Message Broker）不執行任何調度,轉換,或復雜的路由;相反,它只是一個輕量級訪問遠程服務組件的傳輸工具。
  集中式消息拓撲結構通常應用在較大的業務應用程序中，或對于某些對傳輸層到用戶接口層或者到服務組件層有較復雜的控制邏輯的應用程序中。該拓撲較之先前討 論的簡單基于REST的拓撲結構，其好處是有先進的排隊機制、異步消息傳遞、監控、錯誤處理和更好的負載均衡和可擴展性。與集中式代理相關的單點故障和架 構瓶頸問題已通過代理集群和代理聯盟（將一個代理實例為分多個代理實例，把基于系統功能區域的吞吐量負載劃分開處理）解決。
</ul>


圖 4-4

1.3 避免依賴和調度

微服務架構模式的主要挑戰之一就是決定服務組件的粒度級別。如果服務組件粒度過粗，那你可能不會意識到這個架構模式帶來的好處（部署、可擴展性、可 測試性和松耦合）。然而,服務組件粒度過細將導致額外的服務調度,這可能會導致將微服務架構模式變成一個復雜、容易混淆、代價昂貴并易于出錯的、重量級的 面向服務架構。

如果你發現需要從應用內部的用戶接口或API層調度服務組件，那么很有可能你服務組件的粒度太細了。同樣的，如果你發現你需要在服務組件之間執行服務間通信來處理單個請求,要么是你服務組件的粒度太細了，要么是沒有從業務功能角度正確劃分服務組件。

服務間通信，可能導致組件之間產生耦合，但可以通過共享數據庫進行處理。例如，若一個服務組件處理網絡訂單而需要用戶信息時，它可以去數據庫檢索必要的數據，而不是調用客戶服務組件的功能。

共享數據庫可以處理信息需求，但是共享功能呢？如果一個服務組件需要的功能包含在另一個服務組件內，或是一個公共的功能,那么有時你可以將服務組件 的共享功能復制一份，因此違反了DRY規則。為了保持服務組件獨立和部署分離，微服務架構模式實現中會存在一小部分由重復的業務邏輯而造成的冗余，這在大 多數業務應用程序中是一個相當常見的問題。小工具類可能屬于這一類重復的代碼。

提示 : DRY，即don’t repeat yourself.

</blockquote>

如果你發現就算不考慮服務組件粒度的級別，你仍不能避免服務組件調度,這是一個好跡象,可能此架構模式不適用于你的應用。由于這種模式的分布式特 性，很難維護服務組件之間的單一工作事務單元。這種做法需要某種事務補償框架回滾事務,這對此相對簡單而優雅的架構模式來說，顯著增加了復雜性。

1.4 注意事項

微服務架構模式解決了很多單體應用和面向服務架構應用存在的問題。由于主要應用組件被分成更小的、單獨部署單元,使用微服務架構模式構建的應用程序通常更健壯,并提供更好的可擴展性,支持持續交付也更容易。

該模式的另一個優點是,它提供了實時生產部署能力，從而大大減少了傳統的月度或周末“大爆炸”生產部署的需求。因為變化通常被隔離成特定的服務組 件，只有變化的服務組件才需要部署。如果你的服務組件只有一個實例，你可以在用戶界面程序編寫專門的代碼用于檢測一個活躍的熱部署,一旦檢測到就將用戶重 定向到一個錯誤頁面或等待頁面。你也可以在實時部署期間，將服務組件的多個實例進行交換，允許應用程序在部署期間保持持續可用性（分層架構模式很難做到這 點）。

最后一個要重視的考慮是，由于微服務架構模式可能是分布式的架構，他與事件驅動架構模式具有一些共同的復雜的問題，包括約定的創建、維護，和管理、遠程系統的可用性、遠程訪問身份驗證和授權等。

1.5 模式分析

下面這個表中包含了微服務架構模式的特點分析和評級，每個特性的評級是基于其自身特點，基于典型模式實現的能力特性,以及該模式是以什么聞名的。

特性 | 評級 | 分析 |
|———–|——–|————-|
| 整體靈活性 | 高 | 整體的靈活性是能夠快速響應不斷變化的環境。由于單獨部署單元的概念,變化通常被隔離成單獨的服務組件,使得部署變得快而簡單。同時，使用這種模式構建的應用往往是松耦合的，也有助于促進改變。 |
| 易于部署 | 高 | 整體來講，由于該模式的解耦特性和事件處理組件使得部署變得相對簡單。broker拓撲往往比mediator拓撲更易于部署，主要是因為event- mediator組件與事件處理器是緊耦合的，事件處理器組件有一個變化可能導致event mediator跟著變化，有任何變化兩者都需要部署。 |
| 可測試性 | 高 | 由于業務功能被分離成獨立的應用模塊,可以在局部范圍內進行測試，這樣測試工作就更有針對性。對一個特定的服務組件進行回歸測試比對整個單體應用程序進行 回歸測試更簡單、更可行。而且,由于這種模式的服務組件是松散耦合的，從開發角度來看，由一個變化導致應用其他部分也跟著變化的幾率很小，并能減小由于一 個微小的變化而不得不對整個應用程序進行測試的負擔。 |
| 性能 | 低 | 雖然你可以從實現該模式來創建應用程序并可以很好的運行，整體來說，由于微服務架構模式的分布式特性，并不適用于高性能的應用程序。 |
| 伸縮性 | 高 | 由于應用程序被分為單獨的部署單元,每個服務組件可以單獨擴展，并允許對應用程序進行擴展調整。例如，股票交易的管理員功能區域可能不需要擴展，因為使用 該功能的用戶很少，但是交易布局服務組件可能需要擴展，因為大多數交易應用程序需要具備處理高吞吐量的功能。 |
| 易于開發 | 高 | 由于功能被分隔成不同的服務組件，由于開發范圍更小且被隔離，開發變得更簡單。程序員在一個服務組件做出一個變化影響其他服務組件的幾率是很小的，從而減少開發人員或開發團隊之間的協調。 |

Android中的微服務架構

在Android領域中，我們最常看到的就是如圖4-5的Android體系架構。



這是一個典型的分層架構，分為應用層、Framework層、Native層、內核層，似乎與我們今天要說的微服務架構沒有任何關系！大家需要注意的是這是一個更宏觀的架構，在這個分層架構之下還有其他的架構模式，微服務架構就是其中最為明顯的一個。

我們知道在Android系統啟動時，大致會執行如下四步:

1. init進程啟動；
2. Native服務啟動；
3. System Server啟動；
4. Android服務啟動，將服務注冊到ServiceManager中；
5. 啟動Launcher程序。
</ol>

而Framework和Native層的架構是如圖 4-6 所示，



總結

來自： http://www.devtf.cn/?p=576