摘要：在這種情況下，每一個微服務(wù)定義一個限界上下文，類似于領(lǐng)域驅(qū)動的限界上下文。設(shè)計你的微服務(wù)系統(tǒng)的響應(yīng)式微服務(wù)架構(gòu)這本書對于微服務(wù)系統(tǒng)架構(gòu)很有幫助。

1.Lagom概念介紹

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

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

2.Lagom設(shè)計理念

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

3.在多語言系統(tǒng)中的Logam

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

4.開發(fā)環(huán)境概述

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

5.Lagom構(gòu)建基本思想

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

6.組件技術(shù)

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

7.API概述

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

8.設(shè)計你的微服務(wù)系統(tǒng)

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

替換掉大塊系統(tǒng)
當(dāng)設(shè)計一款微服務(wù)系統(tǒng)來替換掉一個大的系統(tǒng)時候，依賴于需求額和已存在的架構(gòu)，你的方案可能各不相同。例如，如果它是很好很合理設(shè)計的，你首先可能不會與遺留組件進(jìn)行連接，并在當(dāng)前專注
于遷移功能。如果合理的停機(jī)時間是不被接受的，你需要仔細(xì)計劃，從舊系統(tǒng)中選擇可用的老的功能以用于新的服務(wù)中。
比如，設(shè)想一個為多個部門處理核心業(yè)務(wù)功能的企業(yè)整體應(yīng)用。他也許有被會計，打折，銷售和運營鎖使用的庫存功能----每個模塊以不同的方式使用著它。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.（實在不知道咋翻譯了）。限界上下文可以讓一個小的團(tuán)隊專注于在同一時間，并行的工作在一個上文中。
在第一個實現(xiàn)階段，你可能會修改從發(fā)布會計部門感興趣的一個特定用例的庫存事件來開始修改這個龐然大物的老舊工程系統(tǒng)。下面的圖闡釋了我們的系統(tǒng)發(fā)布事件到Kafka中，kafka是一個指定
訂閱/發(fā)布模式的流式平臺。并且kafka可以作為一個集群運行，那樣可以提供更好的性能和可靠性。
![圖片描述][1]

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


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

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

9.制定特別的微服務(wù)

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

10.內(nèi)部和外部的交互

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

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

11.注冊和發(fā)現(xiàn)服務(wù)

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

服務(wù)注冊：
服務(wù)注冊表與微服務(wù)實例進(jìn)行協(xié)作，以維護(hù)最新的查找表。注冊表包括每個可用的微服務(wù)實例的主機(jī)和端口。當(dāng)負(fù)載變化時，系統(tǒng)可以在任何位置生成或銷毀實例，同時繼續(xù)滿足請求。您可以設(shè)計一個系統(tǒng)，使微服務(wù)能夠自動注冊，或者您可以使用第三方注冊服務(wù)

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

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

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

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

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

13.管理數(shù)據(jù)持久性

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

14.事件源ES的優(yōu)勢

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

在一個分布式體系結(jié)構(gòu)中,事件采購提供了以下優(yōu)點

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

15.讀寫分離

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

17.部署可伸縮的彈性系統(tǒng)

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

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