摘要：在這種情況下，每一個微服務定義一個限界上下文，類似于領域驅動的限界上下文。設計你的微服務系統的響應式微服務架構這本書對于微服務系統架構很有幫助。

1.Lagom概念介紹

lagom框架包含一系列的可以支持我們從開發到部署的庫以及開發環境：
>在開發階段，可以通過一個簡單的命令構建我們的項目，啟動所有你的服務，并且可以支持所有的lagom基礎設置層。當你修改了代碼，logom是有熱加載的。開發環境可以讓你在幾分鐘內添加進一個新的服務或者加入一個現有的lagom開發團隊
>你可以使用java或者scala創建微服務。Lagom為服務通信提供了一個特別的的無縫體驗。服務定位，通信協議以及其他的問題都被Lagom處理掉了，提供了方便和效率。同時，Lagom對于持久化是支持ES（事件源）和CQRS(命令查詢職責分離)的。
>在任意你選擇的平臺上部署。為了簡化部署，Lagom有很多可以開箱機用的產品組件，比如Application Monitoring(監控的)。這些產品組件提供了一種在容器環境中的簡單的方式來部署，測量，監控和管理Logam服務

設計一個達到高伸縮和面對意想不到的失敗具有彈性微服務系統是機器苦難的，如果沒有Lagom這樣的框架，你需要去處理在高度的分布式系統中所有復雜的線程和并發的問題，你是可以避免這些缺陷,同時提高工作效率的。Logam允許你在現有的約束下采用響應式架構。例如你可以想下面這樣創建微服務：
 >與遺留系統/或者替換程序的整體功能
 >使用Cassandra或者你自己選擇的數據庫和/或與其他數據存儲集成
 

2.Lagom設計理念

考慮由Jonas Bonér提出的響應式微服務的一些基礎的需求：
>隔離是彈性和靈活力的先決條件并且服務邊界之間的消息通訊是異步
>自主服務通過發布它的協議/API只能保證自己的行為。服務需要可被尋址的，它應該是位置透明的
>現在需要的是，每一個微服務都為自己的狀態和持久化負責
如下的這些特性，促進這些最佳實踐：
>lagom默認是異步的---他的API讓服務間通信通過一流的流的概念。所有的Lagom API為了異步的流而使用AKKA Stream的異步的IO能力；java API使用jdk1.8的CompletionStage來處理異步計算；scala使用Future
>與傳統的中央管理的數據庫對比，Lagom傾向分布式的持久化模式。我們鼓勵--但不是必須--事件源的架構來持久化。Lagom的默認的持久化實體的模式是采用ES（事件源）與CQRE結合的方式。為什么事件源那么重要呢，下面多帶帶解釋下：
    ES管理數據持久化：
    當我們設計微服務時候，需要記住每一個微服務都應該有自己的數據和直連的數據庫，其他的服務使用服務API于數據進行交互。但是這里不能在不同的服務間共享數據庫，因為這會導致服務
    之間的緊耦合。
    在這種情況下，每一個微服務定義一個限界上下文，類似于DDD領域驅動的限界上下文。
    為了實現解耦的架構，Lagom的持久化促進了ES和CQRS的使用。事件源是捕獲所有的改變當做領域事件的實踐，即已經發生的不可改變的事實。舉例，在一個使用ES的系統中，當Mike從他的銀
    行賬戶中取出錢，那個事件就可以被簡單存儲為“￥100.00 取款”，而不是在CRUD程序中的復雜的相互作用。如果使用CRUD，那么在包裝的事務務提交之前，可能會發生各種各樣的查詢和修改
    操作事件源ES被用于聚合根，就像是攜帶有用戶標識的用戶-Mike一樣。寫的一端完全的約束在聚合中。這就使得很容易去思考維持不變性和驗證傳入的命令。但是有一點不同需要注意，當聚
    合可以回復通過特定的標識符查詢時候時候可以采用這個模型，但是它不能用于服務跨多個聚合的查詢。因此，你需要根據查詢服務提定制化的數據視圖。
    lagom持久化事件流進入數據庫中，事件流處理器，其他服務或者客戶端，讀或者可選擇的，執行，存儲時間。lagom支持persistent read-side processors（讀端持久化處理器）和
    message broker topic subscribers（消息代理主題訂閱者），你當然可以通過raw stream of events(原生事件流)創建你自己的事件流處理器。
    如果你不想使用事件源ES和CQRS，那么你也可以使用其他的在Lagom中的持久化模塊。如果您選擇不使用Lagom持久模塊，Lagom的持久化模塊CassandraSession提供了一個異步的API去存儲
    數據進Cassandra.但是你您可以實現您的Lagom服務與任何數據存儲解決方案
    
    你應該選擇使用其他比Lagom持久化模塊,記得使用異步api來實現最好的可伸縮性。如果您正在使用阻塞api,這樣JDBC、JPA,你應該仔細管理阻塞用專用的線程池的固定/有限大小的組件調用
    這些阻塞api。不要通過幾個異步的調用來串聯阻塞，例如服務API調用。
>Lagom為管理客戶端和服務端發現，提供了一個執行服務注冊和服務網關用于的內部設施的實現。可以查看5.4 Registering and discovering services，有詳細介紹

3.在多語言系統中的Logam

Lagom并不期待你的系統中的每個服務都是Lagon服務，畢竟，使用微服務的最大的優勢，就是首先為每個微服務可以選擇最適合的語言或者技術。Lagom的標準通信協議習慣用法的和通用兼容設計驅
動的API讓它可以在一個多種語言的系統工作的很好。
Lagom服務調用映將同步通信射到標準HTTP，將流或者異步的消息映射到WebSockets。任何語言的框架支持這些協議的話，都是可以很簡單的消費Logam服務，相反,Lagom服務可以很容易跟任何暴露
REST API的服務交互。
一個Loagom服務的API指定了服務如何使用HTTP。REST服務調用被HTTP的URL和METHOD標識，而請求而和相應的頭部信息則是可以自定義的。Lagom的信息是被序列化了的，默認下是用Json，使用
慣用的的一些映射庫來簡單的讓Json在線表現出來

4.開發環境概述

通過maven或者sbt可以很快的開發出Lagom項目。

5.Lagom構建基本思想

如果做得好,采用活性microservice架構可以大大提高開發組織的效率和速度。Lagom 提供靈活構建方法，支持個人及團隊的發展，并且可以隨著時間的推移而發展。你可以把你所有的微服務放在
當個maven項目中，每一個服務都可以被分開構建，或者構建多個服務構成的一個組。
下面是我們需要開率的一些利弊：
    >多帶帶構建多服務：（單一版本）
        >開發新功能往往需要同時處理多個服務.讓那些服務在相同的構建中無沖突的開發體驗。
        >然而,隨著開發人員構建的數量增加,彼此之間會減緩開發效率
    >多次構建，對于每個服務管著一組小的服務（維護多個版本）
        >每個微服務都可以獨立的改變并且被隔離開來開發的也會更快。在realise的時候，依賴的服務就可以更新以使用更新后的新的服務
        >然而，多個版本增加了復雜度，您需要發布服務讓他們對其他服務是可用的。實現還需要導入在某版本下的特別的依賴。 Splitting a system into multiple builds講了如何
        解決這種麻煩
    在開始的時候，他通常在同一個構建中保持所有的服務是有意義的。
    比如當一個系統整處于功能開發階段，你可以將服務拆分，分別構建。同樣的原則也適用于團隊工作。重要的是需求與構建要同步。

6.組件技術

作為一個完整的微服務平臺，Lagom聚集了技術的集合并在他們之上添加價值，一些庫文件，工具，以及lagom使用和支持的服務器等都在Lightbend中很成熟了。其他的第三方資源，當您在lagom框
架下開發,您還可以利用這些技術:
>AKKA----Lagom的持久化，發布訂閱和節點都是在AKKA基礎上實現的。Lightbend具有即時構建，分布式和彈性的消息驅動程序的工具集
    >跨多個服務器擴展微服務，Lagom提供的AKKA Cluster可以提供聚集
    >在實現服務描述,Lagom服務可以很‘簡小’或者‘流式’，建立在AKKA strams之上Lagomm服務
>Cassandra 默認的持久化
>Guice 類似于playkuangjia，Lagom使用它完成依賴的注入
>play框架
>slf4j logback日志
>Typesafe Config Library:Lagom和它的許多組件技術是使用類型安全配置庫配置
>序列化 jackson

7.API概述

Lagom提供了java和scala的API。java版本的API是假定你已經熟悉了新特定，例如lambda和默認方法，和Optional接口等java1.8的知識。Lagom的絕大多數是用scala實現的，但是這些實現的
細節不是你應該關系你的，你應該知識專注于java的API開發。
Lagom提供的服務接口文檔讓開發者可以快速的定義接口并立即實現他們。
你使用的那些重要的API包括：
    >"服務API"：提供了一種方法來聲明和實現服務接口以供應客戶端使用。位置透明性,客戶發現服務通過服務定位器.服務API支持異步流媒體服務之間除了同步請求-響應調用
    >消息代理API:提供了可以通過主題進行發現數據的分布式的發布訂閱模型。一個話題就是一個允許服務去push或者push數據的通道。
    >持久化：為存儲數據的服務提供了事件源持久化實體。Lagom管理持久化實體的分布在集群節點,使得我們可以切分和水平擴展。lagom管理持久化實體的分布在集群節點,使得我們可以
    切分和水平擴展。Cassandra是作為一個數據庫提供開箱即用的,但其他數據庫也是支持的。

8.設計你的微服務系統

Bonér的響應式微服務架構這本書對于微服務系統架構很有幫助。要想有處理復雜的領域的能力，是需要時間和經驗的。Lagom提供的API可以為你提供實用的指導。
我們建議先從小開始，首先，確定一個可以消費異步消息的簡單的微服務需求，它不需要很復雜甚至提供了大量的屬性值。部署簡單可以降低了風險，可以快速的成功。然后，在架構層面，
拿出一個可以劃分的核心服務,并把它劃分進微服務系統中，當你們一次一次的碰到問題處理問題，那么你和你的團隊的開發效率會越來越高效。使用想DDD這樣的思想可以幫助你可以你的團隊
處理企業系統固有的復雜性

替換掉大塊系統
當設計一款微服務系統來替換掉一個大的系統時候，依賴于需求額和已存在的架構，你的方案可能各不相同。例如，如果它是很好很合理設計的，你首先可能不會與遺留組件進行連接，并在當前專注
于遷移功能。如果合理的停機時間是不被接受的，你需要仔細計劃，從舊系統中選擇可用的老的功能以用于新的服務中。
比如，設想一個為多個部門處理核心業務功能的企業整體應用。他也許有被會計，打折，銷售和運營鎖使用的庫存功能----每個模塊以不同的方式使用著它。DDD鼓勵這樣一個龐大而笨拙的模型分解
成有限的上下文。Each Bounded Context defines a boundary that applies to a particular team, addresses specific usage, and includes the data schema and physical 
elements necessary to materialize the system for that context.（實在不知道咋翻譯了）。限界上下文可以讓一個小的團隊專注于在同一時間，并行的工作在一個上文中。
在第一個實現階段，你可能會修改從發布會計部門感興趣的一個特定用例的庫存事件來開始修改這個龐然大物的老舊工程系統。下面的圖闡釋了我們的系統發布事件到Kafka中，kafka是一個指定
訂閱/發布模式的流式平臺。并且kafka可以作為一個集群運行，那樣可以提供更好的性能和可靠性。
![圖片描述][1]

接下來，就想下面的這個圖片展示的，你可能創建一個微服務，訂閱這個主題，拉取處理kafka的數據。一個微服務的多個實例可以提供高伸縮性和容錯性。遺留功能就扔可以在你測試或者微調的
微服務中保存下來。
![圖片描述][2]


然后，想接下來的這個圖片展示的，你可能會修改這個龐然大物般的系統，讓其調用HTTTP與新的微服務交互，來代替全部的業務邏輯都走自身體統
![圖片描述][3]

這個內部的業務邏輯從本來的龐大的系統，遷移到了新的微服務或者一組微服務中。而這也只是將功能點前移除龐大系統的一種高層次的方式

9.制定特別的微服務

無論你是從一個亂寫的，或者分解一個龐然大物般的大系統進微服務，下面的這些問答可以幫助你：
問：一個服務職能做一件事嗎？
答：是的。如果你不能使用一個短句就能完整的表示一個為服務于的完整目的，那么你的服務可能會龐大，例如：
    >一個適當大小的服務：“這個服務在用戶之間管理者友好的關系”
    >服務執行多種功能，應該被分解掉：“這個服務管理著用戶的朋友關系，聚合所有的用戶的朋友的活動，所以它可以被消費掉”
問：服務應該是自治的嗎？
答：一個服務應該為自己的行為負責。不應該依賴于其他的服務來處理它的事情。
    例如，考慮一個訂單服務，服務的協議允許你創建一筆訂單，添加訂單的各種分類。添加支付的詳情，確認訂單的支付。然而，有一個其他的系統處理這支付，如果這堵的服務沒有運行會
    怎么樣呢？？這種依賴性意味著訂單服務不是自治，它依賴了支付這個領域
    一個自治服務會接受確認請求無論支付服務的狀態。
    一個自治的服務應該接收確認請求，無論付款服務的狀態是什么。他還有可能是異步的方式，確保付款最終被處理完成。
問：這項服務擁有其自己的數據嗎？
答：一個服務，如果他是唯一的從數據庫中寫和讀的服務，那么它就可以擁有自己的數據。
如果你發現你設計的多個服務從同一個數據庫拿取數據，那么就該考慮下設計了。選擇一個服務作為所有者,需要其他服務使用該服務的協議取讀取

10.內部和外部的交互

如前面在第二小節討論的，服務應該被隔離并且是自治的。這樣的服務通過網絡發送消息的形式，與其他的服務進行交互。為了實現服務的實現性能和韌性，你應該經常通常是在在不同的節點
運行行多個相同的服務實例，內部的交互也是在網絡上。此外,第三方和/或遺留系統也可能為microservice系統消耗或提供信息。
下列主題更詳細地討論這些通信路徑:
①在微服務內部交互
在原則上相似，但是網絡上的交互和內部的交互有著不同的需要，Lagom提供了多種實現選項。服務間通信必須使用松耦合的協議和保持隔離和自治的消息格式。協調不同服務之間的變更可能會很困難，而且成本高昂。您可以利用以下的優勢在您的系統中實現這一點：
    >Service calls,要不同步，要么異步，允許服務去與其他的服務使用發布的API和標準的協議（例如HTTP協議或者說是WenSocket）進行交互。
    >發布消息到代理，例如像時候Apache的kafka，將進一步實現解耦。Lagom的Message Broker API（消息代理代理API）提供了至少一次的語義。如果一個新實例開始發布信息，它的消息被添加到先前發出的事件中。如果一個新實例訂閱一個主題，它們將接收所有事件、過去、當前和未來(只要它們已訂閱)。
    
單個服務的節點（統稱為一個集群）需要更小的耦合。他們共享相同的代碼，并由一個團隊或個人共同管理。由于這個原因，服務間通信可以可以利用具有較少開銷和更好性能的機制。例如：
    >很多lagom的組件內部使用AKKA remoting。你可以直接在你的服務中使用它
    >分布式的發布-訂閱可以被用用于低延遲，節點之間至多一次消息。限制包括：
        1.網絡中斷會導致消息丟失。
        2.當一個新實例啟動時，加入集群，并訂閱，它將不會收到在訂閱之前發送的消息。
    >數據庫和其他持久性存儲可以看作是服務通信的節點的另一種方式.對于使用持久實體的微服務,lagom鼓勵使用事件流，而且它還可以運用異步的交互，并可以通過事件日志提供保證。

這張圖展示了在三個服務器上分布的lagom系統中各類型的服務間和服務內通信。在示例中，Order服務發布到一個或多個Kafka主題，而用戶服務訂閱該信息。用戶服務使用Akka remoting與其他用戶服務實例(集群成員)進行通信。通過在服務調用中流傳輸服務和用戶服務交換信息
    ![圖片描述][4]
    
在微服務系統之外與各方進行溝通
Lagom促進了異步通信的使用，在必要時不阻止同步通信的使用。第三方可以從發布到代理API的Lagom服務異步獲取數據，并享受至少一次的保證。Lagom服務還公開了第三方以同步交換數據的API。這通常映射到HTTP。Lagom服務api也通過websocket支持將數據流到外部客戶端。有關更多信息，請參見服務描述符。
與外部世界的交互可能意味著使用互聯網服務的客戶，如瀏覽器、移動應用程序或物聯網設備。在使用標準HTTP或WebSockets時，典型的客戶機不直接與單個服務通信。通常，網絡邊界作為一個邊界，一個受控制的通信點充當外部世界與內部世界之間的中介。在Lagom，這個通信點是一個服務網關。設想你的微服務系統是一個中世紀的城市，周圍有一堵墻，只有一扇門提供進出的唯一通道。墻壁內的交流是免費和直接的，但是來自外部世界的通信必須通過服務網關，如下圖所示：
![圖片描述][5]

11.注冊和發現服務

為了具有彈性和可擴展性，系統必須支持位置透明性。這就可以允許你在不同的主機上運行相同的微服務實例，當出現問題的時候可以讓一個實例從一個主機到另外的地方，增加主機的數量以實現負載變化。在這樣的反應系統中，微服務實例一直在移動，客戶端和其他微服務都需要一種方法來定位可用的服務實例
在開發期間，Lagom為您的微服務系統提供以下功能:
1.服務注冊
2.客戶端服務發現
3.服務端服務發現

服務注冊：
服務注冊表與微服務實例進行協作，以維護最新的查找表。注冊表包括每個可用的微服務實例的主機和端口。當負載變化時，系統可以在任何位置生成或銷毀實例，同時繼續滿足請求。您可以設計一個系統，使微服務能夠自動注冊，或者您可以使用第三方注冊服務

當啟動一個Lagom microservice實例時，注冊者將注冊微服務的名稱，服務注冊表上的本地服務描述符的URL和名稱，這樣他們就可以被定位了。在為服務提供一個實例時，注冊員也必須更新服務注冊表。Lagom的開發環境提供了一個服務注冊中心和注冊中心的實現，這樣您就可以在本地運行您的微服務。
許多可用的技術提供服務注冊中心功能，您需要選擇和/或為您的服務開發一個服務定位器，以便在您的部署環境中運行(例如，Lagom ZooKeeper服務定位器)。你可能需要找到一種方法來將你的Lagom服務與注冊商連接起來。Lagom的ConductR（這個東西我會在快速開始的那個里面講）方式的集成使得這兩個步驟無縫銜接。

客戶端一端的服務發現
引自Bonér’s 的Reactive Microservices Architecture: Design Principles for Distributed Systems書：
    一旦存儲了每個服務的信息，就可以通過服務注冊中心提供服務，服務注冊中心可以使用一個名為客戶端服務發現的模式來查找信息
Lagom為每個服務描述符創建服務客戶機，以便應用程序可以與Lagom服務進行交互。假設一個非lagom應用程序想要使用hello服務，它可以使用welcome service客戶端并簡單地調用hello方法。welcome service的客戶端想要使用服務注冊表，找到一個有效的 URL，在那個地址下welcome服務是可用和完成請求。這種方法需要使用Lagom提供的代碼。在生產中，插入服務的服務定位器將是參與此客戶端發現的一個元素。在后續的快速開始哪里的Integrating with non-Lagom services這一節，你可以看到更多使用情況.

服務端發現：
引自Bonér’s 的Reactive Microservices Architecture: Design Principles for Distributed Systems書：
    另一個策略是信息存儲和維護在一個負載均衡器[…]使用一種稱為服務器端服務發現的模式。
如果不能在每個客戶機上嵌入服務定位器，則可以使用服務器端服務發現。此模式使用服務網關允許客戶端使用服務描述符注冊提供的端點。在這個模型中，瀏覽器只需要知道服務網關在哪里。當使用服務器端發現時，只有在調用被添加到ACL時才能到達服務描述符的調用。
例如，瀏覽器可以通過請求服務網關中的/ hello / steve路徑向用戶顯示hello消息。這時服務網關將會知道哪一個服務提供這個端點，而且會向服務注冊中心請求該服務的一個實例。服務注冊中心將可以響應請求的實例的主機和端口返回。最后，服務網關將執行請求并將結果返回給瀏覽器。
為了簡化服務器端服務發現的測試，Lagom開發環境下會啟動所有服務以及服務注冊中心和服務網關。

12.使用不可變的對象 （immutable objects）

一個從被創建了之后就不可以被修改的不可變對象有如下的優點：
    >基于不可變對象的代碼更清晰，更有可能是正確的。涉及意外變化的錯誤根本無法發生。
    >多個線程可以同時安全地訪問不可變的對象。
在Lagom中，不可變對象在如下的幾個地方是必須的，例如:
    >服務請求和響應類型
    >持久的實體命令、事件和狀態
    >發布和訂閱郵件
Lagom并不關心如何定義不可變對象。您可以手工編寫構造函數和getter，但是我們建議使用第三方工具來生成它們。使用第三方工具，如Immutables工具或Lombok，比手工編寫更容易，也更不易出錯，而且生成的代碼更短，更容易閱讀。
以下各節將提供關于immutables的更多信息:
    >Mutable and immutable examples(可變和不可變的例子)
    >Lombok的例子
    >Immutables tool example(Immutables 工具的例子)
Mutable and immutable examples(可變和不可變的例子):
    在一個可變對象的下面例子中，setter方法可以用于在構建后修改對象:
    ![圖片描述][6]
簡單的不變性
Lombok example
    下面的示例展示了使用Lombok實現的用戶的定義。Lombok為您處理以下細節
        >將屬性變為privte和final
        >為每一個屬性創建getter方法
        >重寫equals和hashcode方法和更加友好的toString
        >創建一個滿屬性的構造器
    下面是樣例，使用的是注解方式
    ![圖片描述][7]
    上圖中的實例并沒有展示出Lombok的一些其他非常有用的注解，例如@Builder或者@Wither，它們可以幫助你創建生成器和復制方法。請注意，Lombok不是一個不可更改的庫，而是一個代碼生成庫，這意味著一些設置可能不會創建不可變的對象。例如：Lombok的@Data是等價于@Lombok的@Value。但是還會合成可變方法。當創建不可變類不要使用Lombok的@Data
    那么如何使用Lombok呢？？
    step1.加入maven
        
            org.projectlombok
            lombok
            1.16.12
        
    step2.與IDE集成
        與IntelliJ IDEA 集成，你需要一個Lombok Plugin for IntelliJ IDEA插件，并開啟注解驅動。 (Settings / Build,Execution,Deployment / Compiler / Annotation Processors and tick Enable annotation processing)
        與eclipse集成：run運行 java -jar lombok.jar,這里有小視頻：https://projectlombok.org/
        
        
Immutables tool example（Immutables工具樣例）
    下面是使用Immutables的用戶(如上面的ImmutableUser)的相應定義:
    ![圖片描述][8]
    mmutables generates for you:
        >構建器(在類有很多字段時非常方便)
        >正確的實現，hashCode,toString,equals
        >來基于舊的實例來復制方法來創建新實例,例如 withEmail
    使用方法step1.
        
            com.lightbend.lagom
            lagom-javadsl-immutables_2.11
            ${lagom.version}
        
    step2.與IDE集成
        eclipse:https://www.lagomframework.com/documentation/1.3.x/java/ImmutablesInIDEs.html#Eclipse
        IDEA:https://www.lagomframework.com/documentation/1.3.x/java/ImmutablesInIDEs.html#IntelliJ-IDEA
    
    Collections:
        如果一個不可變對象包含一個集合，那么集合也必須是不可變的。
        下面是一個具有可變集合的對象的例子:
        ![圖片描述][9]
        上述的例子，只有final的private屬性，方法不提供屬性的set方法，只提供getter方法。但是，列表對象是可以產生原處修改的，比如我們調用getter（）方法獲取到集合，但是我們就可以調用集合的add方法。
        一個可能的修復將使列表防御在構造函數復制和使用 Collections.unmodifiableList 在 getter，像這樣︰
        ![圖片描述][10]
        但這種方式，進行編碼時,它是容易犯錯誤，我們再次建議想下面這樣讓不可變的處理：
        下面的這是ImmutableUser2的定義：
        ![圖片描述][11]
        getPhoneNumbers方法將返回一個實例com.google.common.collect.ImmutableList    
    guava和PCollections
        如上面所示，不可變對象默認使用Guava immutable collections 
        Guava collections要比簡單的java.util.collections要好。但是Guava在某些操作的時候是稍顯笨重的（例如：對于當前存在的collection做一個稍微修改的拷貝）
        因此，我們推薦pcollection，它是一個集合庫，它是為不可變性和效率而設計的。
        上面的示例看起來像使用一個PCollection:
        ![圖片描述][12]        
        這是如何定義由空集合初始化的可選集合
        ![圖片描述][13]
        
        持久化‘collections’
        有兩種不同的，有可能混淆的用法的關于數據的“持久化”一次。、
        您將在pcollection文檔和其他地方看到“持久”數據結構的引用。“”持久化“”這個單詞的意思意味著即使您構建了一個已修改的集合副本的最初的‘persists’.在本文檔的其余部分中，“持久化”指的是持久存儲，如持久化實體和下面的示例。
    進一步的閱讀：
    Immutables文檔在這里有更多關于不可變集合的詳細信息。https://immutables.github.io/immutable.html#array-collection-and-map-attributes

13.管理數據持久性

在設計微服務時，請記住每個服務都應該擁有它的數據并直接訪問數據庫。其他服務應該使用服務API來與數據交互。必須在不同的服務之間不共享數據庫，因為這會導致服務之間過于緊密的耦合。這樣，每個微服務都在一個清晰的邊界內運行，類似于域驅動設計中的有限上下文策略模式。
為了實現這種分離的體系結構，Lagom的持久性模塊促進了事件源和CQRS的使用。事件源是將所有變更捕獲為域事件的實踐，這是已經發生的事情的不可變事實。例如：在一個使用ES的系統中，當邁克把錢從他的銀行賬戶里拿出來的時候，這一事件可以簡單的存儲為"取出100.00 美元"。而不是像在CRUD應用程序中進行的復雜交互，在包裝事務提交之前，需要進行各種讀取和更新操作。
 事件源被用于聚合根，像在以前的樣例中（聚合根的信息，可以去看我的關于聚合根的博文）的帶有唯一標識ID的客戶Mike，，write-side在聚合中保持一致。這樣就可以很容易地解釋一些事情，比如維護不變量和驗證傳入命令。當你采用這個模型的時候的一個顯著的不同點，您需要注意的是，聚合可以回答特定標識符的查詢，但不能用于服務跨多個聚合的查詢。因此，您需要創建針對服務提供的查詢定制的數據的另一個視圖。
 Lagom將事件流持久化到數據庫中。事件流處理器、其他服務或客戶機、讀取和選擇、操作、存儲事件。Lagom提供persistent read-side processors和 message broker topic subscribers。當然，你也可以使用raw stream of event創建自己的時間流.
 如果您不想使用事件源和CQRS，您可能應該使用其他東西，而不是在Lagom中的持久性模塊(不過，我們建議您先閱讀事件采購的優勢。)如果你選擇不使用Lagom的持久性模塊，在Lagom持久性模塊中，CassandraSession提供了用于存儲Cassandra數據的異步API。但是，您可以使用任何數據存儲解決方案來實現您的Lagom服務。
 如果您選擇使用其他東西，而不是Lagom的持久性模塊,記住要使用異步api以獲得最佳的可伸縮性.如果你使用阻塞的APIs，例如JDBC或者JPA，您應該通過使用固定/有限大小的專用線程池來仔細管理阻塞api的組件。不要通過幾個異步調用(例如服務API調用)來串聯阻塞。
 
 

14.事件源ES的優勢

多年來,開發人員實現持久性使用傳統的創建、讀取、更新、刪除(CRUD)模式。正如前面介紹的,如果采購模型實現持久性存儲狀態更改為歷史事件捕獲業務活動發生之前寫的數據存儲。這將事件存儲機制,允許他們被聚合,或者放在一個組與邏輯邊界。事件采購的模式之一,使并發、分布式系統實現高性能、可伸縮性和彈性。

在一個分布式體系結構中,事件采購提供了以下優點

>在傳統的CRUD模型中,實體實例通常會表示為一個可變對象在內存和一個可變行關系數據庫表中。這導致了臭名昭著的對象關系阻抗失配。對象關系映射器是用來填補這一鴻溝,但帶來新的復雜性。
事件源ES模型對待數據庫就像對待一個序列化時間的append-only log一樣。它并不試圖對每個實體的狀態或直接在數據庫模式之間的關系進行建模。這大大簡化了代碼從數據庫中寫入和讀取
>一個實體如何達到其當前狀態的歷史仍在存儲事件。事務型數據和查賬式數據之間的一致性是有保證的,因為這些是相同的數據
>你現在有能力分析事件流和重要的業務信息來自它——也許甚至都不考慮當時的事件設計。你可以在我們的系統活動中添加新的視圖而不會使寫入方面更加復雜
>由于所有類型的事件都都只需添加到數據存儲區，所以它可以提高寫入性能。這里沒有更新和刪除
>事件源系統很容易測試和調試。命令和事件可以模擬用于測試目的。事件日志提供了一個良好的記錄進行調試。如果在生產中檢測到一個問題,你可以回放事件日志在受控環境中了解一個實體進入不好
的狀態。     
 

15.讀寫分離

 編寫或保存數據的功能與讀取或查詢數據的功能完全不同。實現讀寫分離，能夠獨立地提供最好的經驗，試圖將讀和寫的操作封裝一起的模型很少有好的表現。
 在CQRS模式下，寫的一端的實體集中于更新命令，并且您可以對不同類型的查詢和報告作業進行優化。這種分離實現更好的可伸縮性，因為read-side可以獨立地擴展到多個節點上，并且它通常位于需要大量可伸縮性的read-side上。
 例如：在競價系統中，“take the write”是非常重要的，答復投標人我們已盡快接受了投標，這意味著寫吞吐量是最重要的。同樣的應用程序可能會有一些復雜的統計視圖，或者分析師可能會使用這些數據來找出最佳的競標策略和趨勢，這些read-side用例通常需要某種表達性查詢功能和不同的數據模型，而不是寫端。將讀取端與寫端分離的結果是最終的一致性，對寫端的更新可能無法立即在readside中可見。
 
 

17.部署可伸縮的彈性系統

 實現真正的響應式系統：
 >將您的微服務部署到集群中，這樣它們就可以按要求按要求伸縮，并且在面對網絡瓶頸或故障時保持彈性，以及硬件或軟件錯誤
 >確保系統所依賴的組件(例如服務網關和message broker)不暴露單點故障。
 >使用數據存儲的功能來提供冗余或復制
 您可以在您的選擇的適當技術上部署，Lagom支持產品套件開箱即用。Lightbend產品套件是為Llagom的一個完美的匹配。它提供；了如下的特性：
     >一種與打包工件分開管理配置的方法
     >跨多個節點的整合日志。
     >自動重新啟動意外終止服務的監控系統。
     >能夠輕松快速地伸縮自如。
     >處理網絡故障，特別是那些可能導致大腦分裂的問題。
     >自動種子節點發現，確保服務的新實例與已經運行的服務聯接相同的集群。
     >他能夠對你的服務進行滾動更新。
     >支持跨集群的監視服務。
     >在生產前在本地測試服務的能力。
     
     

好的，下面請參考另外的文檔Lagom reference guide（Lagom參考指南）