微服務框架Lagom介紹之一

背景

Lagom是JAVA系下響應式 微服務框架，在閱讀本文之前請先閱讀微服務架構設計，Lagom與其他微服務框架相比，與眾不同的特性包括：

• 目前，大多數已有的微服務框架關注於簡化單個微服務的構建——這是比較容易的一部分內容。Lagom將其擴展到了微服務所構成的系統，這是大型的系統——也是較為困難的一部分內容，因為在這里我們會面臨到分布式系統的復雜性。
• 通信默認是異步的——基於消息和流——但是，如果需要的話，也考慮到了使用其他的方案，如同步的REST。
• 持久化默認是基於事件的——使用事件溯源Event Sourcing和CQRS——但是，如果需要的話，也支持JPA和NoSQL這些技術。
• 完整的集成開發環境，通過這個環境，用一條命令就能管理上百的微服務。在整個服務中，支持自動化地代碼熱重載，並且能夠與IDE以及其他工具進行集成。開發環境是基於生產環境（通過使用ConductR）的，因此支持直接在生產環境下部署和擴展

Lagom是基於Reactive理念的（這種理念定義在Reactive宣言之中）。它有很多特定的含義並且指導了Lagom的設計，其目標在於使直接做“正確的事情”變得更加容易，並為此提供了保護措施，也就是好的默認實現。但是，如果你有合理的理由並且明白自己在做什么的話，也是允許對其進行更改的。

Lagom倡導一些核心的原則，並使它們更易於實現，這些原則如下所示：

• 通過非共享的設計，實現真正的隔離：這意味着Lagom中的服務都是自我管理、松耦合以及位置可變的（對位置透明）——對於可恢復性和彈性來講，這都是必要的需求。在Lagom中，微服務是基於如下技術構建的：
  • Akka Actors：基於Actor模型實現了非共享架構（share nothing architecture），從而提供了隔離性。
  • Akka Cluster：微服務系統是由一組獨立且互相隔離的服務所組成的，Akka Cluster為這些服務提供了可恢復性、分區、復制、可擴展性以及負載均衡。
  • ConductR：從最底層提供了隔離性，為微服務實例實現運行時管理。
• 職責單一：在Unix哲學中，有一條古老的原則：“所編寫程序要只做一件事，並將其做好”，這條原則幫助很多開發人員編寫的程序符合如下的特點：只有一項目標、很小但是具備定義良好的責任並且能夠很容易地與其他小程序進行組合。這是很明智的，在這個更加關注微服務的時代，它會比以往更加重要。這其實與規模大小沒有什么關系。微服務這個詞其實很糟糕，因為它會讓我們關注規模大小和代碼行數。通過移除大多數的樣板式代碼，Lagom會試圖簡化設計，能夠讓我們關注於服務的本質，同時創建明晰的協議也會變得很容易，不管這些協議是通過異步消息、請求/響應還是通過持續的流來進行組合的。
• 服務持有其數據：：每個服務不僅要有行為，還要持有它的數據，服務會一直延伸到持久層。在Lagom中，默認的持久化模型使用的是事件溯源和CQRS——使用Akka Persistence和Cassandra——它具有很強的可擴展性、易於復制和保持完全的彈性。另外，它的審計和調試也很棒，能夠在任意時間點及時地重放和探查事件日志。它還避免了傳統的對象-關系阻抗不匹配，過去我們都是使用像JPA和Hibernate這樣的ORM技術來擺脫它所帶來的困擾。也就是說，使用微服務的一個好處就是服務可以根據所要解決的問題自由選擇最合適的持久化模型，也就是所謂的Polyglot Persistence。
• 始終保持異步：在Lagom中，通信和IO默認都是異步和無阻塞的，這也是Reactive系統設計的基石。它的好處在於：通過更高效地使用資源，這種方式更加划算；它有助於最小化系統中對共享資源的競爭（擁擠）——在實現可擴展性、低延遲以及高吞吐量方面，這通常是最大的負擔所在；它有助於創建更加松耦合的系統，從而實現動態性、可用性和彈性。基於微服務的系統要擁抱這樣的現實，那就是要能夠應對如今現實世界的挑戰。

技術

AKKA- --- Lagom的持久化，發布訂閱和節點都是在AKKA基礎上實現的。Lightbend具有即時構建，分布式和彈性的消息驅動程序的工具集 >跨多個服務器擴展微服務，Lagom提供的AKKA Cluster可以提供聚集 >在實現服務描述,Lagom服務可以很‘簡小’或者‘流式’，建立在AKKA strams之上Lagomm服務
Cassandra 默認的持久化

Lightbend ConductR容器編排工具，實現彈性服務 Guice 類似於playkuangjia，Lagom使用它完成依賴的注入 Play框架 SLF4J & Logback日志 Typesafe Config Library:Lagom和它的許多組件技術是使用類型安全配置庫配置 序列化 jackson

相關技術鏈接

• Scala
• Java
• Play Framework
• Akka and Akka Persistence
• sbt
• Cassandra
• Guice
• ConductR

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

快速開始

開發環境

1. configuring Java:
* On systems running Linux
* On MacOS
* On Windows systems

java version "1.8.0_74"Java(TM) SE RuntimeEnvironment(build 1.8.0_74-b02)JavaHotSpot(TM)64-BitServer VM (build 25.74-b02, mixed mode)

2. Maven 3.2.1 or higher

To install Maven, see the official Maven installation page.

或 sbt 0.13.5 or higher

Sbt文檔documentation

Maven構建安裝

mvn archetype:generate -Dfilter=com.lightbend.lagom:maven-archetype-lagom-java 

官方但速度比較慢，可以使用阿里雲Maven鏡像，配置文件參考

從maven官方找到 http://repo1.maven.org/maven2/archetype-catalog.xml

<archetype>
<groupId>com.lightbend.lagom</groupId>
<artifactId>maven-archetype-lagom-java</artifactId>
<version>1.3.3</version>
<description>maven-archetype-lagom-java</description>
</archetype>

我們使用方式如下:

mvn archetype:generate -DgroupId=com.lightbend.lagom -DartifactId=maven-archetype-lagom-java 

輸入

com.lightbend.lagom:maven-archetype-lagom-java

然后選擇最新版本1.3.3, 最新版本可能變化，序號是15

項目結構是

cassandra-config
hello-api
hello-impl
integration-tests
pom.xml
stream-api
stream-impl

運行

mvn lagom:runAll

[info]Starting embedded Cassandra server
..........[info]Cassandra server running at 127.0.0.1:4000[info]Service locator is running at http://localhost:8000[info]Service gateway is running at http://localhost:9000...[info]Service hello-impl listening for HTTP on 0:0:0:0:0:0:0:0:24266[info]Service stream-impl listening for HTTP on 0:0:0:0:0:0:0:0:26230(Services started, press enter to stop and go back to the console...)

在瀏覽器運行， 看到輸出說明正常了。

http://localhost:9000/api/hello/World

示例項目

在官方2個示例項目,我們選擇其中一個

git clone https://github.com/lagom/activator-lagom-java-chirper.git

下載后進入目錄

運行mvn lagom:runAll

開始下載其相關依賴包，時間較長，其中還包括了前端的React.js打包， 最后輸出如下：

從上面我們看到Cassandra數據庫監聽4000端口，服務locator在8000端口，網關gateway在9000端口, UI是這樣的：

模塊：

Chirp service: 負責存儲聊天，提供存儲接口服務
Friend service: 負責用戶存儲，管理朋友關系
Activity Stream service: 為聊天提供流數據的支持，依賴於 Chirp與Friend 服務
Front-End service: 提供前台用戶UI

項目結構

在IntelliJ IDEA中通過Maven導入, 如下圖

通訊過程

通過UI的操作，我們能夠抓起其通訊的HTTP請求，

1.發消息

POST http://localhost:9000/api/chirps/live/peter HTTP/1.1
Host: localhost:9000
Connection: keep-alive
Content-Length: 34
Accept: */*
Origin: http://localhost:9000
X-Requested-With: XMLHttpRequest

{"userId":"peter","message":"message"}

HTTP/1.1 200 OK
Content-Length: 0
Date: Mon, 19 Jun 2017 13:15:46 GMT

2.用戶注冊

POST http://localhost:9000/api/users HTTP/1.1
Host: localhost:9000
Connection: keep-alive
Content-Length: 31
Accept: */*
Origin: http://localhost:9000
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.104 Safari/537.36
Content-Type: application/json
Referer: http://localhost:9000/signup

{"userId":"lucy","name":"tian"}

3.用戶查詢

GET http://localhost:9000/api/users/lucy HTTP/1.1
Host: localhost:9000

HTTP/1.1 200 OK
Content-Length: 44
Content-Type: application/json; charset=utf-8
Date: Mon, 19 Jun 2017 13:17:02 GMT

{"userId":"lucy","name":"tian","friends":[]}

4. 跳過網關，直接查詢friend-api，注意我們訪問60399端口試試

GET http://localhost:60399/api/users/lucy HTTP/1.1
Host: localhost:60399

5.增加friends

POST http://localhost:9000/api/users/lucy/friends HTTP/1.1
Host: localhost:9000

{"friendId":"peter"}

Summary

     “謹慎使用微服務”這句話說的沒錯。在人們使用微服務時，如果不夠謹慎，那么在行業生產中會造成巨大的反作用，如果沒有正確使用，你會經歷混亂，然后退縮，並且抗拒改變。但是，我們需要注意的是，我們需要一個能夠在系統構建層面提供抽象的框架，用於封裝架構最佳實踐。所以，在構建微服務時遇到的錯誤或讓你頭疼的地方。

     微服務的用途在於分解一個單體，但其目的不是在於分解一個單體，而是為了能讓你更快的向客戶和用戶實現交付。它們需要更快的交付功能，能夠讓你的系統容錯性更強，具備隔離性，以及能讓你的系統隨時間變得更強大，隨時間發展，以及在系統的壽命周期內變得更加成熟。現在，改變發生的太快，所以快速改變系統，快速構建系統，以及修改它的能力已經成了使用微服務、以及用一致的方式管理微服務者必須注意的一個領域，它能幫助你的系統優雅地走向成熟。

      響應式還需要處理容錯和靈活性問題，而容錯和靈活性是在構建系統時必須考慮的問題。當你僅僅進行響應式編程時，如果你在構建一個單體，或者一個響應性單體，或許你可以暫時忽略它，但是你一旦開始將系統組合起來，那些需要相互連接並協同工作的系統的容錯能力、彈性和靈活性就是你必須考慮到的。不依賴一個粗粒度災難恢復類型的解決方案，這種方案一般僅使用容器、VM或一些東西來說明自己的彈性；而應該在依賴外部容器、或VM、或雲平台之前就多多少少在應用層面具備彈性，這兩者之間是有些細微差別的。

--------------------------------------------------------------------------------------------------------------------------------------------

今天先到這兒,希望對您在系統架構，團隊管理, 項目管理,產品管理 有參考作用 , 您可能感興趣的文章:
互聯網電商購物車架構演變案例
互聯網業務場景下消息隊列架構
消息系統架構設計演進
互聯網電商搜索架構演化之一
企業信息化與軟件工程的迷思
企業項目化管理介紹
軟件項目成功之要素
人際溝通風格介紹一
精益IT組織與分享式領導
學習型組織與企業
企業創新文化與等級觀念
組織目標與個人目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共享
高效能的團隊建設
項目管理溝通計划
構建高效的研發與自動化運維
某大型電商雲平台實踐
互聯網數據庫架構設計思路
IT基礎架構規划方案一(網絡系統規划)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之采購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之性能實時度量系統演變

如有想了解更多軟件設計與架構, 系統IT,企業信息化, 團隊管理 資訊，請關注我的微信訂閱號：

作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。
該文章也同時發布在我的獨立博客中-Petter Liu Blog。