前言
對于開發人員來說，在沒有正規架構的情況下開始編寫應用程式是很常見的。如果沒有清晰且定義良好的體系結構，大多數開發人員和架構師通常會采用傳統的分層體系結構模式(也被稱為N層體系結構)，将源代碼子產品分離到各個包中，進而形成所謂的分層。遺憾的是，這樣做的結果隻會得到一組沒有組織的源碼子產品，這些子產品之間缺乏清晰的角色、職責和關系。
缺乏正規架構的應用程式通常是強耦合的、脆弱的、難以更改的，且沒有明确的願景或方向。是以，如果不完全了解系統中每個元件和子產品的内部工作原理，就很難确定應用程式的體系結構特征。關于部署和維護的這些基本問題就很難回答：架構是否可伸縮？應用程式的性能特征是什麼？應用程式對于需求變更的響應是否容易？應用程式的部署特征是什麼？架構的響應性如何？
架構模式有助于定義應用程式的基本特征和行為。比如，有些架構模式适用于需要高可伸縮性的應用程式，而有些架構模式适用于需要高靈活性的應用程式。為了選擇滿足特定業務的需求和目标，了解每種架構模式的特征、優缺點是很有必要的。
作為架構師，你必須始終能證明你的架構決策是正确的，特别是在標明架構模式或方法時。
1. 分層架構(Layered Architecture)
最常見的架構模式是分層架構模式，即N層架構模式。這種模式是大多數Java EE應用程式事實上的标準，是以被多數架構師、設計人員和開發人員所熟知。很多公司内的傳統IT通信群組織都采用分層架構，是以這種架構模式也成為多數業務應用程式開發的自然選擇。
1.1 模式描述
分層架構模式中的元件被組織到各個水準層中，每一層在應用程式中執行特定的角色(例如，表示邏輯或業務邏輯)。盡管分層架構模式沒有指定必須存在于架構中的層的數量和類型，但大多數分層體系結構由四個标準層組成：表示層、業務層、持久化層和資料庫層(圖1-1)。在某些情況下，業務層和持久化層被組合成一個單一的業務層，特别是當持久化邏輯(例如SQL或HSQL)嵌入到業務層元件中時。是以，較小的應用程式可能隻有三層，而較大或更複雜的業務應用程式可能包含五個層或更多層。
Figure 1-1. Layered architecture pattern
分層架構模式的每一層在應用程式中都有特定的角色和職責。例如，表示層負責處理使用者接口，而業務層負責處理與請求相關的具體業務。該架構模式中的每一層都圍繞滿足特定業務請求所需完成的工作形成了一個抽象。例如，表示層不需要知道或關心如何擷取客戶資料；它隻需要在螢幕上以特定格式顯示該資訊。類似地，業務層不需要關心如何格式化客戶資料以便在螢幕上顯示，甚至不需要關心客戶資料來自何處;它隻需要從持久層擷取資料，對資料執行業務邏輯(例如，計算值或聚合資料)，并将該資訊傳遞到表示層。分層體系結構模式的強大功能之一是元件之間的關注點分離。特定層中的元件隻處理屬于該層的邏輯。例如，表示層中的元件隻處理表示邏輯，而駐留在業務層中的元件隻處理業務邏輯。這種類型的元件分類使得在你的架構中建構有效的角色和責任模型變得容易，并且由于定義良好的元件接口和有限的元件範圍，也使得應用這種架構模式開發、測試、治理和維護應用程式變得容易。
1.2 Key Concepts(關鍵概念)
注意在圖1-2中，該架構中的每一層都被标記為關閉的。這是分層架構模式中一個非常重要的概念。封閉的層意味着當請求從一層移動到另一層時，它必須通過它下面的一層才能到達更下面的一層。例如，來自表示層的請求必須先經過業務層，然後到達持久層，最後才能到達資料庫層。
Figure 1-2. Closed layers and request access
那麼為什麼不允許表示層直接通路持久層或資料庫層呢?畢竟，從表示層直接通路資料庫要比通過一堆不必要的層來檢索或儲存資料庫資訊快得多。這個問題的答案在于一個被稱為層隔離的關鍵概念。
層隔離概念意味着在架構的某一層中所做的更改通常不會影響其他層中的元件。如果你允許表示層直接通路持久層，那麼持久層中的SQL如果變更了，可能會影響到業務層和表示層，這樣就會産生一個緊耦合的應用程式，元件之間會有很多依賴關系。這種架構會變的很難維護。
層隔離的概念也意味着每一層都獨立于其他層，是以不需要了解架構中其他層的内部工作原理。
雖然封閉的層有助于層隔離，也有助于隔離架構内的更改，但有時使某些層開放也是有意義的。例如，假設你想向架構中添加一個共享服務層，這層包含很多業務層中元件要通路的公共服務元件(例如，資料和字元串實用程式類或審計和日志類)。在這種情況下，建立服務層通常是一個好主意，因為從架構上講，它将對共享服務的通路限制在業務層(而不是表示層)。如果沒有單獨的層，在架構上就沒有任何東西可以限制表示層通路這些公共服務，是以也就很難控制這種通路限制。
在這個例子中，新的服務層可能位于業務層下面，該服務層中的元件無法被表示層通路。然而，這就産生了一個問題，業務層必須通過服務層才能到持久層，這顯然沒啥意義。這是分層架構中的一個老問題了，可以通過建立一個開放層來解決。
如圖1-3所示，在這種情況下，服務層被标記為開放的，這意味着請求可以繞過這個開放層，直接轉到它下面的層。在下面的示例中，由于服務層是開放的，是以業務層現在可以繞過它直接進入持久層，這非常有意義。
Figure 1-3. Open layers and request flow
利用開放層和封閉層的概念有助于定義架構中層和請求流之間的關系，也為設計人員和開發人員提供必要的資訊，以了解架構内的各種層通路限制。如果不能記錄或正确地交流架構中的哪些層是開放的，哪些層是關閉的(以及為什麼)，通常會産生非常難以測試、維護和部署的緊密耦合且脆弱的架構。
1.3 Pattern Example(示例)
為了闡述分層架構是如何工作的，考慮來自使用者的一個檢索某個客戶資訊的請求(Figure 1-4)。黑色箭頭表示向下流到資料庫的請求，紅色箭頭表示向上流到螢幕顯示資料的響應。這個例子中，客戶資訊包括客戶資料和訂單資料(客戶下的訂單)。
Figure 1-4. Layered architecture example
客戶螢幕負責接受請求并顯示客戶資訊。它不知道資料在哪裡、如何檢索資料，也不知道必須查詢多少個資料庫表才能獲得資料。一旦客戶螢幕接收到擷取特定個人的客戶資訊的請求，它就會将該請求轉發到customer delegate(客戶委托)子產品。customer delegate子產品知道業務層中的哪些子產品可以處理這個請求，還知道如何通路業務層中的這個子產品以及這個子產品需要什麼資料。業務層中的customer object(客戶對象)負責聚合請求的所有資訊。該子產品調用持久化層中的customer dao (data access object) 子產品擷取客戶資料，也調用order dao擷取訂單資訊。customer dao和order dao子產品依次執行SQL語句來檢索相應的資料并将其傳遞回業務層中的customer object。一旦customer object收到資料，它就會聚合資料并将該資訊回傳給customer delegate，然後customer delegate将這些資料再傳回客戶螢幕呈現給使用者。
從技術角度來看，這些子產品實際上有幾十種實作方式。
1.4 Considerations
分層架構模式是一種可靠的通用模式，使其成為多數應用程式的良好起點，特别是當你不确定哪種架構模式最适合你的應用程式時。然而，當選擇這種架構模式時，有些方面需要考慮：
首先要關注的是所謂的architecture sinkhole anti-pattern(反模式)。此反模式描述了這樣一種情況，即請求在架構的多個層中流動，簡單的做透傳處理，在每一層中執行很少或不執行邏輯。例如，假設表示層響應使用者檢索客戶資料的請求。表示層将請求傳遞給業務層，業務層将請求傳遞給持久層，然後持久層對資料庫層進行簡單的SQL調用以檢索客戶資料。然後，資料被一路傳回堆棧，不需要額外的處理或邏輯聚合、計算或轉換資料。
每個分層架構都會至少有一些落入反模式的場景。然而，關鍵在于分析屬于這一類請求的百分比。遵循8-2規則通常是确定是否正在經曆反模式的好辦法。典型的情況是，大約20%的請求是簡單的透傳，80%的請求具有與請求相關的業務邏輯。但是，如果你發現這個比例相反，并且大多數請求都是簡單的透傳處理，那麼你可能需要考慮使一些架構中的層開放，請記住，由于缺乏層隔離，控制更改将更加困難。
另外一個注意事項是，即使你将表示層和業務層分割為獨立的部署單元，這個模式也更适用于單塊應用程式。雖然對于某些應用程式來說，這可能不是一個問題，但它确實在部署、一般健壯性和可靠性、性能和可伸縮性方面提出了一些潛在的問題。
1.5 Pattern Analysis(模式分析)
Overall agility(整體靈活性)
評級：低
分析：整體靈活性是快速響應環境不斷變化的能力。雖然可以通過此模式的隔離層特性隔離變更，但在此體系結構模式中進行更改仍然很麻煩且耗時，因為大多數實作都具有單片特性，并且通常使用此模式的元件之間存在緊密耦合。
Ease of deployment(易部署性)
評級：低
分析：受該架構模式具體實作的影響，部署可能會稱為一個問題，特别是對于較大的應用程式。一個元件的小更改，就可能需要重新部署整個應用程式或者應用程式的很大一部分。是以，這種模式不容易形成持續傳遞，這就進一步降低了易部署性方面的總體評級。
Testability(易測性)
評級：高：
分析：由于元件從屬于該架構模式中的特定層，是以其他層是可以被mock或stub的，這就使得分層架構模式相對容易測試。開發人員可以模拟表示層 中的元件來隔壁業務元件中的測試，也可以模拟業務元件來測試表示層。
Performance(性能)
評級：低：
分析：雖然某些分層架構确實運作的很好，但由于必須通過架構的多層來實作業務請求的低效率，這種模式并不适合于高性能應用程式。
Scalability(可擴充性/可伸縮性)
評級：低：
分析：由于這種模式的緊密耦合和通用實作的趨勢，使用這種體系結構模式建構的應用程式通常難以擴充。您可以通過将層拆分為單獨的實體部署或将整個應用程式複制到多個節點來擴充分層體系結構，但總體而言，粒度太寬，使得擴充成本很高。
Ease of development(可開發性)
評級：高：
分析：開發的容易程度得到了相對較高的分數，主要是因為這種模式非常有名，而且實作起來并不太複雜。因為大多數公司通過分層(表示、業務、資料庫)分離技術來開發應用程式，使得這種模式成為大多數業務應用程式開發的自然選擇。公司的溝通群組織結構與軟體開發方式之間的聯系被稱為Conway’s law。你可以谷歌“Conway’s law”來獲得更多關于這種迷人相關性的資訊。
2. 事件驅動架構( Event-Driven Architecture )
事件驅動架構模式是一種流行的分布式異構模式，用于生成高可伸縮的應用程式。它還具有很強的适應性，既可以用于小型應用程式，也可以用于大型複雜應用程式。事件驅動架構由高度解耦的、單一用途的事件處理元件組成，這些元件異步接收和處理事件。
事件驅動架構模式由兩個主要拓撲結構組成，mediator(中介) 和 broker(代理)。中介拓撲通常用于需要通過中心中介在事件中編排多個步驟的情況，而代理拓撲則用于希望在不使用中心中介的情況下将事件連結在一起的情況。由于這兩種拓撲結構的架構特征和實作政策不同，是以了解每種拓撲結構以了解哪種拓撲結構最适合您的特定情況是非常重要的。
2.1 Mediator Topology(中介拓撲)
Mediator Topology對于具有多個步驟并且需要某種級别的編排來處理事件的事件非常有用。例如，進行股票交易的單個事件可能需要您首先驗證交易，然後根據各種合規規則檢查該股票交易的合規性，将交易配置設定給經紀人，計算傭金，最後與該經紀人進行交易。所有這些步驟都需要某種程度的編排，以确定步驟的順序，以及哪些步驟可以串行執行，哪些步驟可以并行執行。
在Mediator Topology中，有四種主要類型的架構元件：event queues(事件隊列), event mediator(事件中介器), event channels(事件管道), 和 event processors(事件處理器)。事件流從用戶端向事件隊列發送事件開始，該事件隊列用于将事件傳輸到event mediator。事件中介器接收初始事件，并通過向事件通道發送額外的異步事件來編排該事件，以執行流程的每個步驟。事件處理器監聽事件通道，從事件中介接收事件，并執行特定的業務邏輯來處理事件。如圖2-1所示。
Figure 2-1. Event-driven architecture mediator topology
在事件驅動的體系結構中，通常有十幾個到幾百個事件隊列。該模式沒有指定事件隊列元件的實作；它可以是消息隊列、web服務端點或它們的任何組合。
此模式中有兩種類型的事件: an initial event(初始事件)和a processing event(處理事件)。初始事件是被中介器接受的原始事件，而處理事件是由中介器生成并由事件處理元件接收的事件。事件中介器元件負責編排初始事件中包含的步驟。對于初始事件中的每一步，事件中介器向事件通道發送一個特定的處理事件，然後由事件處理器接收和處理。需要注意的是，事件中介實際上并不執行處理初始事件所需的業務邏輯; 相反，它知道處理初始事件所需的步驟。
事件中介器使用事件通道，将與初始事件中的每個步驟相關的特定處理事件異步傳遞給事件處理器。事件通道既可以是消息隊列，也可以是消息主題。其中，消息主題常與中介拓撲一起使用，是以處理事件可以由多個事件處理器處理(每個處理器根據接收到的處理事件執行不同的任務)。
事件處理器元件包含處理“處理事件”所需的應用程式業務邏輯。事件處理器是自包含的、獨立的、高度解耦的體系結構元件，在應用程式或系統中執行特定的任務。雖然事件處理器元件的粒度可以從細粒度(例如，計算訂單上的銷售稅)到粗粒度(例如，處理保險索賠)不等。但需要特别記住，一般來說，每個事件處理器元件都應該單獨形成一個業務任務，而不依賴于其他事件處理器。
事件中介器可以以多種方式實作。作為架構師，您應該了解這些實作選項中的每一個，以確定您為事件中介器選擇的解決方案符合您的需求和要求。
事件中介器最簡單和最常見的實作是通過開源內建中心，如Spring Integration、Apache Camel或Mule ESB。這些開源內建中心的事件流通常是通過Java代碼或DSL(領域特定語言)實作的。對于更複雜的中介和編排，可以将BPEL(業務流程執行語言)與BPEL引擎(如開源Apache ODE)結合使用。BPEL是一種标準的類xml語言，用于描述處理初始事件所需的資料和步驟。對于需要更複雜的業務流程的大型應用程式(包括涉及人工互動的步驟)，您可以使用業務流程管理器(BPM)(如jBPM)實作事件中介器。
了解您的需求并将其與正确的事件中介器實作相比對，對于使用此拓撲的任何事件驅動體系結構的成功都至關重要。使用開源內建集線器來執行非常複雜的業務流程管理編排是一種失敗的方法，就像實作BPM解決方案來執行簡單的路由邏輯一樣。
為了說明中介拓撲如何工作，假設您通過一家保險公司投保，并決定遷移。在這種情況下，初始事件可能被稱為類似于relocation event(重新定位事件)的東西。處理重定位事件所涉及的步驟包含在事件中介器中，如圖2-2所示。對于每個初始事件步驟，事件中介都會建立一個處理事件(例如，更改位址、重新報價等)，将該處理事件發送到事件通道，并等待相應的事件處理器(例如，客戶流程、報價流程等)處理“處理事件”。這個過程會一直持續，直到初始事件中的所有步驟都被處理完畢。The single bar over the recalc quote and update claims steps in the event mediator indicates that these steps can be run at the same time.
Figure 2-2. Mediator topology example
2.2 Broker Topology(代理拓撲)
代理拓撲與中介拓撲的不同之處在于沒有中心事件中介器；相反，消息流通過輕量級消息代理(例如ActiveMQ、ActiveMQ)以鍊式方式分布在事件處理器元件之間。當你有一個相對簡單的事件處理流并且不需要(或不需要)中心事件編排時，此拓撲非常有用。
在代理拓撲中有兩種主要類型的架構元件：broker(代理元件)和event processor(事件處理器元件)。代理元件可以集中或聯合，并包含事件流中使用的所有事件通道。代理元件中包含的事件通道可以是消息隊列、消息主題或兩者的組合。
如圖2-3所示。從圖中可以看出，沒有控制和編排初始事件的中心事件中介器元件; 相反，每個事件處理器元件負責處理一個事件，并釋出一個訓示它剛剛執行操作的新事件。例如，平衡股票投資組合的事件處理器可能會接收一個稱為股票拆分的初始事件。基于初始事件，事件處理器可能會執行一些投資組合再平衡，然後向broker釋出一個名為投資組合再平衡的新事件，随後這個新事件由不同的事件處理器接收。請注意，有時事件由事件處理器釋出，但沒有被任何其他事件處理器提取。這在開發應用程式或提供未來的功能和擴充時，是很常見的。
Figure 2-3. Event-driven architecture broker topology
為了說明代理拓撲如何工作，我們将使用與中介拓撲中相同的示例(投保人移動)。由于在代理拓撲中沒有接收初始事件的中心事件中介器，是以客戶-流程元件直接接收事件，更改客戶位址，并發送一個表示更改了客戶位址的事件(例如，更改位址事件)。在本例中，有兩個事件處理程式對更改位址事件感興趣: the quote process(報價流程)和the claims process(索賠流程)。報價處理元件根據位址更改重新計算新的汽車保險費率，并向系統的其餘部分釋出一個事件，訓示它所做的工作(例如，recalc報價事件)。報價處理元件根據位址更改重新計算新的汽車保險費率，并向系統的其餘部分釋出一個事件，訓示它所做的工作(例如，重新報價事件)。另一方面，索賠處理元件接收相同的更改位址事件，但在本例中，它更新了未償付的保險索賠，并将事件作為更新索賠事件釋出到系統。然後這些新事件被其他事件處理器元件拾取，事件鍊繼續貫穿整個系統，直到沒有針對特定的初始事件釋出更多的事件。
Figure 2-4. Broker topology example
從圖2-4中可以看到，代理拓撲完全是關于執行業務功能的事件連結。了解代理拓撲的最佳方法是将其視為接力賽。在接力賽中，運動員拿着接力棒跑一段距離，然後把接力棒交給下一個運動員，以此類推，直到最後一個運動員越過終點線。在接力賽中，一旦運動員交出接力棒，她就結束了比賽。代理拓撲也是如此:事件處理器一旦交出事件，就不再參與特定事件的處理。
2.3 Considerations
事件驅動的體系結構模式是一種相對複雜的實作模式，這主要是由于它的異步分布式特性。在實作此模式時，必須解決各種分布式體系結構問題，例如遠端程序可用性、缺乏響應性以及在代理或中介失敗時的代理重連邏輯。
在選擇這種架構模式時需要重視的一個因素是單個業務流程缺少原子事務。由于事件處理器元件是高度解耦和分布式的，是以在它們之間維護事務工作單元非常困難。是以，在使用這種模式設計應用程式時，必須不斷考慮哪些事件可以獨立運作，哪些事件不能獨立運作，并相應地規劃事件處理器的粒度。如果您發現需要跨事件處理器分割單個工作單元——也就是說，如果您使用單獨的處理器處理某個本應是不可分割事務的事務——這個模式可能不是适合您的應用程式。
2.4 Pattern Analysis
Overall agility(整體靈活性)
評級：高
分析：整體靈活性是快速響應環境不斷變化的能力。由于事件處理器元件是單一用途的，并且與其他事件處理器元件完全解耦，變更通常與一個或 幾個事件處理器隔離，并且可以在不影響其他元件的情況下快速進行。
Ease of deployment(易部署性)
評級：高
分析：總的來說，由于事件處理器元件的去耦特性，這個模式相對容易部署。代理拓撲結構往往比中介拓撲結構更容易部署，主要是因為事件中介 元件與事件處理器緊密耦合: 事件處理器元件的更改可能也需要事件中介的更改，對于任何給定的更改都需要部署兩者。
Testability(易測性)
評級：低
分析：雖然單個單元測試并不太難，但它确實需要某種專門的測試用戶端或測試工具來生成事件。測試也因為這種模式的異步特性而變得複雜。
Performance(性能)
評級：高
分析：當然，由于涉及到所有的消息傳遞基礎設施，實作一個事件驅動的體系結構并不能很好地執行是有可能的，但總的來說，該模式通過其異步 功能來實作高性能;換句話說，執行解耦的并行異步操作的能力超過了消息排隊和解排隊的成本。
Scalability(可擴充性)
評級：高
分析：在這種模式中，通過高度獨立和解耦的事件處理器自然可以實作可伸縮性。每個事件處理器都可以單獨伸縮，進而實作細粒度的可伸縮性。
Ease of development(可開發性)
評級：低
分析：由于模式和契約建立的異步特性，以及需要在代碼中為響應不及時的事件處理器和失敗的代理提供更進階的錯誤處理條件，是以開發可能有些複雜。
3. Microkernel Architecture ( 微核心架構 )
微核心架構模式(有時稱為插件架構模式)是實作基于産品的應用程式的自然模式。基于産品的應用程式是作為典型的第三方産品打包并提供版本供下載下傳的應用程式。然而，許多公司也像軟體産品一樣開發和釋出他們的内部業務應用程式，包括版本、釋出說明和可插拔功能。這些也很适合這個模式。微核心架構模式允許您将額外的應用程式功能作為插件添加到核心應用程式，提供可擴充性。
微核心架構主要包含兩類元件：a core system(核心系統) 和 plug-in modules(插件子產品)。應用程式邏輯被拆分到獨立的插件子產品和核心系統中，以支援擴充性、靈活性，應用程式特性隔離和自定義處理邏輯的能力。
微核心架構中的“核心系統”通常僅包含使系統具備可操作的最小功能。許多作業系統都實作了微核心架構模式，這也是這個模式名字的由來。從應用程式業務的角度來看，核心系統通常被定義為通用業務邏輯，沒有針對特殊情況、特殊規則或複雜條件處理的自定義代碼。
插件子產品都是獨立的元件，其中包含特定的處理、附加特性和用于增強或擴充核心系統以産生附加業務功能的自定義代碼。通常地，插件子產品之間應該是彼此獨立的，但是你也可以設計一個需要其他插件介入的插件。不管怎樣，保持插件間最小的互動代價，以避免依賴問題，這一點是很重要的。
核心系統需要知道哪些插件是可用的以及如何擷取這些插件。一種常見的實作方式是通過某種插件系統資料庫。這個系統資料庫包含了每個插件子產品的資訊，比如名字，資料協定，遠端通路協定細節(依賴于插件如何被連接配接到核心系統)。例如，标記高風險稅務審計項目的稅務軟體插件系統資料庫項，可能包含服務名稱(AuditChecker)，資料協定(input data and output data)和格式化協定(XML)。如果這個軟體可以通過SOAP通路，它可能還含有WSDL(Web Services Definition Language)。
插件子產品可以通過多種方式與核心系統建立連接配接，比如OSGI(open service gateway initiative)，消息，web服務，或者直接點對點綁定(比如，對象執行個體化)。連接配接類型取決于你正在建構的應用程式類型(小産品還是大業務應用)和你的具體需求(比如，單體部署還是分布式部署)。這個架構模式除了要求插件子產品之間必須保持彼此獨立外，并沒有指定上述的實作細節。
3.2 Pattern Examples
微核心架構的最好示例是Eclipse IDE。下載下傳Eclipse後，它隻提供一個漂亮的編輯器。你可以給它不斷的添加插件，它的功能也會越來越多。另一個應用微核心架構的常用産品是網際網路浏覽器。
基于産品的軟體例子數不勝數，但大型業務應用程式呢？微核心體系結構也适用于這些情況。為了說明這一點，讓我們使用另一個保險公司的例子，這次涉及保險索賠處理。
索賠處理是一個非常複雜的過程。每個州對于保險索賠中允許和不允許的内容都有不同的規則和規定。例如，如果你的擋風玻璃被石頭損壞，一些州允許免費更換擋風玻璃，而其他州則不允許。這為标準索賠流程創造了幾乎無限的條件集。
不足為奇的是，大多數保險索賠應用程式利用大型複雜的規則引擎來處理這種複雜性。然而，這些規則引擎可能會發展成一個複雜的大泥球，其中更改一個規則會影響其他規則，或者進行一個簡單的規則更改需要大量的分析人員、開發人員和測試人員。使用微核心體系結構模式可以解決許多這些問題。
在圖3-2中看到的檔案夾堆棧表示索賠處理的核心系統。它包含保險公司處理索賠所需的基本業務邏輯，除非不進行任何自定義處理。每個插件子產品都包含所代表州的特殊規定。在本例中，插件子產品可以使用自定義源代碼或單獨的規則引擎執行個體來實作。無論采用何種實作，關鍵的是個别州的特殊規則和處理與核心索賠系統是分開的，可以添加、删除和更改，而對核心系統的其餘部分或其他插件子產品幾乎沒有影響。
Figure 3-2. Microkernel architecture example
3.3 Considerations
微核心架構模式的一個優點是，它可以被嵌入或用作其他架構模式的一部分。比如，為了解決一個特定問題，你發現無法實作整個架構。這種情況瞎，你可以将微核心嵌入到你正在适用的架構模式中(比如，分層架構)。類似地，前面關于事件驅動架構中的事件處理器元件也可以使用微服務體系結構模式實作。
微核心架構模式為設計演變和開發提速提供了很好的支援。您可以首先生成一個可靠的核心系統，然後随着應用程式的逐漸發展，添加特性和功能，而不必對核心系統進行重大更改。
對于基于産品的應用程式，微核心架構模式應該是您初始架構的首選，特别是對于那些随着時間的推移而釋出附加功能并希望控制哪些使用者獲得哪些功能的産品。如果随着時間的推移，你發現這個模式不能滿足你所有的需求，你也總是可以将你的應用程式重構為另一個更适合你特定需求的架構模式。
3.4 Pattern Analysis
以下包含了對微核心架構模式中常見架構特征的評級和分析
Overall agility(整體靈活性)
評級：高
分析：整體靈活性是快速響應環境不斷變化的能力。通過松散耦合的插件子產品，可以很大程度地将變更隔離開來。而且，多數微核架構的核心系統會快速的趨于穩定，健壯，并且随着時間的推移也不需要太多的變更。
Ease of deployment(易部署性)
評級：高
分析：根據模式的實作方式，插件子產品可以在運作時被動态的添加到核心系統上(比如，熱插拔)，最大限度地減少部署期間的停機時間。
Testability(易測性)
評級：高
分析：插件子產品可以單獨測試，并且在幾乎不更改核心系統的情況下來模拟一些特别的特性。
Performance(性能)
評級：高
分析：雖然微核心模式本身并不适用高性能應用程式，但一般來說，大多數使用微核心架構模式建構的應用程式性能都很好，因為你可以自定義和簡化應用程式，以達到隻包含你需要功能的目的。JBoss 服務應用程式就是一個很好的例子: 通過它的插件架構，你可以将應用程式伺服器精簡到隻保留那些你需要的功能，删除昂貴的不使用的功能，如遠端通路、消息傳遞和消耗記憶體的緩存，CPU，線程和減慢應用的服務。
Scalability(可擴充性)
評級：低
分析：因為大多數微核心架構的實作都是基于産品的，通常尺寸較小，且作為獨立單元實作，是以伸縮性不高。雖然根據實作插件子產品的方式，可以在插件級别上提供可伸縮性，但總體而言，這種模式并适用于需要高伸縮性的應用程式。
Ease of development(可開發性)
評級：低
分析：微核心架構需要經過深思熟慮的設計和contract governance，是以實作起來相當複雜。Contract versioning、内部插件注冊中心、插件粒度以及插件連接配接性的廣泛選擇都增加了實作此模式的複雜性。
4. Microservices Architecture Patterne ( 微服務架構 )
微服務體系結構模式作為單片應用程式和面向服務的體系結構的可行替代方案，在行業中迅速獲得了一席之地。因為這個體系結構模式仍在不斷發展，是以業界對于這個模式到底是什麼以及它是如何實作它還存在很多困惑。這一部分隻提供關鍵概念和必要的基礎知識。
4.1 Pattern Description
第一個概念是 separately deployed units(獨立部署單元)。如圖4-1所示，微服務架構中的每個元件都是以獨立單元部署的，且通過高效的傳遞管道和高度的應用程式與内部元件結構，會更容易的進行部署。
Figure 4-1. Basic Microservices architecture pattern
最重要的概念或許是 service component(服務元件)。與其在微服務架構中思考服務，不如在其中思考服務元件，它們的粒度可以從單個子產品到應用程式的很大一部分不等。服務元件包含一個或多個子產品(例如，Java類)，它們要麼代表單一用途的功能(例如，為特定城市或城鎮提供天氣預報)，要麼代表大型業務應用程式的獨立部分(例如，股票交易安排或确定汽車保險費率)。設計合适的服務元件粒度級别是微服務架構中最大的挑戰之一。這一挑戰将在下面的服務元件編制小節中更詳細地讨論。
另一個關鍵概念是，它是一個分布式架構，這意味着架構中的所有元件彼此完全解耦，并通過某種遠端協定通路(例如，JMS, AMQP, REST, SOAP, RMI等)。這種架構的分布式本質是它如何實作一些優越的可伸縮性和部署特性。
關于微服務架構的一個令人興奮的事情是，它是從其他常見架構模式相關的問題演變而來的，而不是作為等待問題發生的解決方案而建立的。微服務架構風格是從兩個主要來源發展而來的：使用分層架構模式開發的單體應用程式和通過面向服務的架構模式開發的分布式應用程式。從單體應用到微服務架構風格的演進路徑主要是通過持續傳遞的開發來推動的，即從開發到生産的持續部署管道的概念，它簡化了應用程式的部署。單體應用程式通常由緊密耦合的元件組成，這些元件是單個可部署單元的一部分，這使得更改、測試和部署應用程式變得繁瑣且困難(是以出現了通常在大多數大型應用程式中常見的“每月部署”周期)。這些因素通常會導緻脆弱的應用程式，每次部署新東西時都會崩潰。微服務體系結構模式通過将應用程式分離為多個可部署單元(服務元件)來解決這些問題，這些單元可以獨立于其他服務元件單獨開發、測試和部署。
導緻微服務架構模式的另一個進化路徑是在應用程式實作面向服務架構模式(SOA)時發現的問題。盡管SOA模式非常強大，并提供了無與倫比的抽象級别、異構連接配接、服務編排以及将業務目标與IT功能對齊的承諾，但它仍然複雜、昂貴、無處不在、難以了解和實作，并且通常對大多數應用程式來說是過度的。微服務體系結構風格通過簡化服務的概念、消除編排需求以及簡化對服務元件的連接配接和通路來解決這種複雜性。
4.2 Pattern Topologies
雖然實作微服務體系結構模式的方法有幾十種，但最常見和最流行的是三種主要拓撲: the API REST-based topology, application REST-based topology, and the centralized messaging topology.
基于REST API的拓撲通常對于暴露少量API且自包含的網站很有用。如圖4-2所示，這種拓撲結構包含非常細粒度的服務元件，每個元件包含一到兩個用于執行特定業務的功能子產品，且不同服務元件中的子產品互相獨立。在這種拓撲中，這些細粒度的服務元件通常使用基于rest的接口進行通路，這些接口的實作通常單獨部署在web的API層。在Yahoo，Google和Amazon中有很多目的簡單的web服務都用到了這種拓撲結構。
Figure 4-2. API REST-based topology
基于REST的應用程式拓撲不同于基于API REST的方法，因為用戶端請求是通過傳統的基于web或胖用戶端的業務應用程式螢幕接收的，而不是通過簡單的API層。如圖4-3所示，應用程式的使用者界面層部署為單獨的web應用程式，通過簡單的基于rest的界面遠端通路單獨部署的服務元件(業務功能)。此拓撲中的服務元件與基于API REST的拓撲中的服務元件不同，因為這些服務元件往往更大、更粗粒度，并且隻代表整個業務應用程式的一小部分，而不是細粒度的單一操作服務。這種拓撲對于複雜性相對較低的中小型業務應用程式很常見。
微服務體系結構模式中的另一種常用方法是集中式消息傳遞拓撲。這種拓撲結構(如圖4-4所示)類似于之前基于REST的應用程式拓撲結構，不同之處在于，這種拓撲結構使用輕量級的集中消息代理(例如，ActiveMQ, HornetQ等)。在檢視此拓撲時，不要将其與面向服務的體系結構模式混淆或将其視為“SOA-Lite”，這一點非常重要。在這種拓撲結構中出現的輕量級消息代理不執行任何編排、傳輸或複雜的路由;相反，它隻是通路遠端服務元件的輕量級傳輸。
Figure 4-4. Centralized messaging topology
集中式消息傳遞拓撲通常出現在較大的業務應用程式或需要對使用者界面和服務元件之間的傳輸層進行更複雜控制的應用程式中。這種拓撲結構優于簡單拓撲結構的優點前面讨論的基于rest的拓撲，包括進階排隊機制、異步消息傳遞、監視、錯誤處理以及更好的整體負載平衡和可伸縮性。通常與集中式代理相關的單點故障和體系結構瓶頸問題通過代理叢集和代理聯合(将單個代理執行個體拆分為多個代理執行個體，以根據系統的功能區域劃分消息吞吐量負載)來解決。
4.3 Avoid Dependencies and Orchestration
微服務架構模式的主要挑戰之一是為服務元件确定正确的粒度級别。如果服務元件太粗粒度，您可能沒有意識到這種架構模式帶來的好處(部署、可伸縮性、可測試性和松耦合)。然而，過于細粒度的服務元件将導緻服務編排需求，這将迅速将你的微服務架構轉變為重量級的面向服務的架構，包括通常在基于soa的應用程式中發現的所有複雜性、混亂性、費用和蓬松性問題。
如果你發現你需要在應用程式的user interface或API layer中編排你的服務元件，那麼說明你的服務元件粒度太細了。類似地，如果你發現你需要在服務元件之間執行服務間通信來處理單個請求，也可能是你的服務元件粒度太細了，或者從業務功能的角度來看它們沒有被正确劃分。
服務間通信可能會導緻元件之間産生不必要的耦合，但可以通過共享資料庫來處理。例如，如果處理Internet訂單的服務元件需要客戶資訊，它可以通路資料庫來檢索必要的資料，而不是在客戶服務元件中調用功能。
共享資料庫可以處理資訊需求，但是共享功能呢?如果一個服務元件需要包含在另一個服務元件中的功能或對所有服務副元件通用的功能，您有時可以在服務元件之間複制共享的功能(是以違反了DRY原則:不要重複自己)。在大多數實作微服務架構模式的業務應用程式中，這是一種相當常見的實踐，為了保持服務元件的獨立性和分離部署，權衡重複業務邏輯的小部分的備援。小型實用程式類可能屬于這類重複代碼。
如果您發現無論服務元件粒度級别如何，仍然無法避免服務元件編排，那麼這可能不是适合您的應用程式的架構模式。由于這種模式的分布式本質，在服務元件之間(或服務元件之間)維護單個事務工作單元是非常困難的。這樣的實踐需要某種用于復原事務的事務補償架構，這就為這個相對簡單而優雅的架構模式增加了極大的複雜性。
4.4 Considerations
微服務架構模式解決了在單體應用程式和面向服務的架構中發現的許多常見問題。由于多數的應用程式元件被分割成較小的、獨立的部署單元，使用微服務架構模式建構的應用程式通常更健壯，提供更好的可伸縮性，并且友善支援持續傳遞。
這種模式的另一個優點是，它提供了實時生産部署的能力，進而大大減少了傳統的每月或周末“大爆炸”生産部署的需求。由于更改通常與特定的服務副元件隔離，是以隻需要部署更改的服務元件。如果隻有服務元件的單個執行個體，則可以在使用者界面應用程式中編寫專門的代碼來檢測活動熱部署，并将使用者重定向到一個錯誤頁面或等待頁面。或者，你可以在實時部署期間交換一個服務元件的多個執行個體，進而允許在部署周期内保持持續可用性(這在分層架構模式中是很難做到的)。
最後一個需要考慮的問題是，由于微服務架構模式是一種分布式架構，它也會遇到一些與事件驅動架構模式相同的負責問題，包括契約建立、維護和管理、遠端系統可用性以及遠端通路身份驗證和授權。
4.5 Pattern Analysis
以下包含了對微服務架構模式中常見架構特征的評級和分析
Overall agility(整體靈活性)
評級：高
分析：由于分離部署單元的概念，變更通常隔離到單個服務元件，這樣部署會快速簡單。此外，使用這種模式建構的應用程式往往是非常松散耦合的，更加有助于更改的友善性。
Ease of deployment(易部署性)
評級：高
分析：由于遠端服務的細粒度和獨立性，微服務模式的部署特性非常高。服務通常作為單獨的軟體單元部署，進而能夠在白天或晚上的任何時間執行“熱部署”。總體部署風險也顯著降低。在這種情況下，失敗的部署能夠更快地恢複，并且隻對正在部署的服務操作有影響，不影響其他操作的繼續操作。
Testability(易測性)
評級：高
分析：由于将業務功能分離和隔離到獨立的應用程式中，測試可以确定範圍，進而允許進行更有針對性的測試工作。針對特定服務元件的回歸測試要比針對整個單片應用程式的回歸測試容易得多，也更可行。此外，由于這種模式中的服務元件是松散耦合的，是以在開發過程中做出更改而破壞應用程式的另一部分的可能性要小得多，進而減輕了為一個小更改而測試整個應用程式的測試負擔。
Performance(性能)
評級：低
分析：雖然你可以通過這種模式建立性能非常好的應用程式，但由于微服務架構模式的分布式特性，這種模式本身并不适合高性能應用程式。
Scalability(可擴充性)
評級：高
分析：因為應用程式被分割為單獨部署的單元，是以每個服務元件都可以單獨伸縮，進而允許對應用程式進行微調。例如，股票交易應用程式的管理區域可能不需要擴充，因為該功能的使用者數量較少，但是交易配售服務元件可能需要擴充，因為大多數交易應用程式需要實作該功能的高吞吐量。
Ease of development(可開發性)
評級：高
分析：由于功能被隔離到獨立的、截然不同的服務元件中，開發變得更容易，因為它的作用域更小、更隔離。開發人員對一個服務元件進行更改而影響其他服務元件的可能性大大降低，進而減少了開發人員或開發團隊之間所需的協調。