概覽

“微服務”是一個非常廣泛的話題，在過去幾年里，市面上存在著各種不同的定義。

雖然對這種架構方式沒有一個非常精確的定義，但仍然有一些概念具有代表性。

微服務有著許多圍繞業務能力、自動化部署、終端智能化、分布式數據以及其他與團隊相關的一些特性。

為了更好地說明，我們參考了Martin Fowler對微服務簡單而具體的定義：

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

GeneXus智能軟件開發平臺，已經能夠并將繼續支持軟件解決方案背后的各種技術架構體系。

要理解什么時候使用微服務架構能夠滿足業務軟件解決方案，首先必須明白微服務架構，并不僅僅是對團隊技術層面的一個挑戰，同時也是關于開發和交付軟件層面的一個全新理念。根據康威定律（Conway’s Law），擁有完整發團隊的公司才能構建完整統一的解決方案。

一個公司應該在成熟度較高的時候再采用微服務架構。即使像亞馬遜、Facebook、Netflix、Uber等這些公司，也都是在解決了人才和技術等相關擴展性的問題后，才采用了微服務架構。

但不管如何，GeneXus 16以及后續的版本能夠比其他任何平臺幫助公司更容易得使用微服務架構。

接下來，我們看一下微服務架構主要會面臨哪些特性和挑戰。

---

?

為什么要使用微服務？

在UX、安全性和集成性等各種需求不斷變化的大環境下，微服務的首要任務就是，保證我們正在開發的系統在需求變化的同時還能夠輕應對。

因為在現實環境中，軟件必須不斷接受改變才能更具競爭力，同時還要聚焦于去適應各種業務場景。

?

■發布

基于微服務架構，我們并不需要發布所有的項目。只需要對涉及到的幾個服務，根據它們的發布周期進行版本管理即可。

尤其是當你有好幾個團隊使用各種不同工具，一起參與同一個龐大的項目時，這是一個非常大的優勢。

?

■效率

您可以去擴展、優化或者變更一個小的業務場景，而不用把所有的模塊放在一起進行評估。

但這時，我們需要團隊之間具有高度的凝聚力，因為這種低耦合意味著需要高度的凝聚力。而為了加強這種團隊之間的凝聚力，我們需要做大量的額外工作，這樣反而有可能會導致我們喪失一定的效率。

?

■組織擴展性

組織的擴展性是使用微服務架構的一個主要優勢。只有具備低耦合的團隊，低耦合的技術，以及低耦合的業務場景，我們才能夠讓不同的團隊，不同的技術和不同的業務場景在同一時間共同推進。

但在帶來這些優勢的同時，微服務架構也會給我們團隊帶來很多的挑戰。

---

?

微服務帶來的挑戰

在使用微服務的同時，也會帶來以下一些挑戰：

■服務組合

正確定義微服務之間的邊界是非常具有挑戰性的。我們需要明白每個微服務必須且只能聚焦在一個業務場景上。

我們必須設計正確的服務邊界，以避免相依性地獄（dependency hell）問題的爆發。現在很多已經使用微服務架構的公司仍然面臨著這些問題。

?

■服務必須有自己的存儲

而由此會帶來一些挑戰和架構決策：

• 數據共享（DATA SHARING）

通常我們會為每個需要進行數據交互的微服務定義API來進行數據共享。我們需要創建一系列的Web服務來進行CRUD操作和數據查詢。

• 數據復制（DATA REPLICATION）

有時候使用API會非常緩慢，必須通過數據復制來加速查詢。

• 事件溯源（EVENT SOURCING）

應用程序將事件保存到事件數據庫中。事件數據庫可以通過API來添加和檢索實體事件。在這種方式下，通過事件溯源，微服務之間的溝通在很多情況下是異步的。

• 原子性和一致性（ATOMICITY AND CONSISTENCY）

因為現在存在好幾個存儲（有一個用于微服務），所以原子操作成了一個新的問題，由此又有了新的模式來解決這個問題。

?

■開發（DEVELOPMENT）

團隊要處理大量的服務，而且這些服務要經常性地被重新發布。所以每個微服務都需要有一個發布計劃和監控的系統。

---

?

GeneXus和微服務

我們認為微服務是一種很抽象的概念和技術。您可以使用任何語言或技術來構建微服務。但后續的維護和實施支撐可能會抵消掉這種系統架構設計帶來的一切優勢。

GeneXus的理念是創建、維護和演進前所未有的軟件解決方案。我們一直致力于在許多方面演進GeneXus產品，以便通過GeneXus能夠去創建未來的系統，尤其是使用微服務架構設計的系統。

我們相信使用GeneXus在面對這些挑戰時，解決的唯一方式是通過基于知識庫的設計，充分了解所有的服務內容，并且掌握維護和演進它們的方法。

?

為什么通過GeneXus來實現微服務是一個不錯的選擇？

? 微服務所有的內容必須由一個小團隊來完成

當您有一個非常完整的團隊架構時，一些工作很有可能會被安排給好幾個不同的團隊來完成。例如，后端服務團隊，安全團隊，數據建模團隊，前端開發人員等等。

而當您在一個微服務體系架構中開發時，您應該聚焦在業務場景。您的團隊一般來說是一個小團隊，但又必須能完成微服務所有層面的工作內容。

而這對于GeneXus開發人員是非常好的，因為GeneXus自一開始就是以這種方式工作的。

?

在開發微服務時，你必須考慮到服務的各個架構層都需要編程（用戶界面層，數據層，業務層）。如果你是使用GeneXus的話，這些工作則會變得簡單且更高效。

在這方面，我們在GeneXus 16中加入了更多的特性，能夠讓一個小團隊使用微服務架構實現一個業務場景的完整功能。

我們加入了UX、集成和安全等方面的一些特性。就GeneXus的UX而言，一個小團隊就可以使用人工智能創建智能終端，也可以為我們的業務場景開發移動APP，Web以及聊天機器人等多體驗的終端應用。

?

? GeneXus可以解決數據演變和共享所面臨的挑戰

數據共享、原子數據、事件溯源等這些問題都可以通過GeneXus來解決。

GeneXus為所有微服務的數據模型演變提供了最佳的解決方式。這些都可以在GeneXus知識庫中通過我們的方法完美實現。

但是對于微服務架構，為了將多個服務隔離開，您可能會有多個知識庫。

GeneXus 16整合了新的數據存儲，這些數據存儲能夠完美匹配一些實現模式（如事件溯源）。我們已經集成了對Kafka、DynamoDB的支持，之后還將繼續添加新的數據源，例如Hyperledger Blockchain，以及更多能夠支持不同實現模式的數據源。

?

我們每兩個月就會發布一個新的版本，很快我們即將發布的版本會實現用更高層級的抽象方式來處理以下幾個微服務模式：

●事件溯源（EVENT SOURCING）

即使在現在的GeneXus版本中，您也可以通過使用例如Serverless和Kafka或DynamoDB或者其他的DBMS來實現此模式。我們正努力實現將事件建模抽象到更高一個層次的方法。

●API演變分析（API Evolution Analysis）

如今，微服務演變的主要關注點之一就是API的演變。對于GeneXus而言，這些工作和數據演變一樣，都能夠自動完成。

●封裝（Encapsulation）

我們正致力于使用知識矩陣（Knowledge Matrix.）來增強模塊（Module）的功能，以及模塊共享的方式。通過其他幾個特性之間的知識矩陣，團隊會具備發現、共享和發布服務的能力。該矩陣將會有一個在線版本和企業內部安裝版本。我們要時刻謹記，微服務的一個主要挑戰就是避免相依性地獄（dependency hell）問題。所以我們將整合幾個工具，以便更廣泛得了解系統是什么。

●觀察（Observable）

當有很多服務時能夠使擴展性得到更大的效果，但每個服務都應該能通過日志或者相關的消息來觀察。

在GeneXus 16中，我們集成了新的日志API，它可以與Elastic Stack（Logstach, Elastic Search 和Kibana）結合使用，以便收集和分析操作信息。

?

? 使用BPM整合微服務

人工智能和工作流是任何行業打造未來系統中最重要的技術。人工智能是當今最熱門的話題話題之一，為了能夠在服務中使用，GeneXus已經集成了一個GeneXus AI模塊。同時我們相信BPM是整合微服務最重要的工具，為此，GeneXus已經內置了一個工作流工具。

BPM仍然在不斷的演進，以解決更復雜的模式，例如SAGAs服務。在微服務架構中，GeneXus有很強的業務流程建模、執行和監控方面的基礎。

?

? 通過GeneXus能夠實現完全的自動化發布

團隊和服務都應該使用自動化技術，這樣才能保證管理和運維的高效。自動化是GeneXus的基礎理念。

如果您不能引入各個開發方面的自動化，那么使用大量的微服務反而會變得一團糟。

?

• GeneXus Server

?將開發流程進行pipeline管理方式，最簡單的開始方法是通過GeneXus和GXserver為項目建立分支/版本模型。

GXserver提供了SCM和PipeLine控制（開發、構建、SCA、測試、原型和發布）

開發/構建 ---> Jenkins Plugin + MSBuild Tasks

SCA ---> KBDoctor and Security Scanner

測試---> GXtest V4

原型和發布--> Docker容器和發布到PaaS或Serverless

?

• 持續集成（CI）

CI意味著每當開發人員在GXserver的KB上進行了一些修改的時候，代碼都會觸發一些自動化操作，以檢查最新的修改是否可以成功得構建一個新版本，而且不會與其他開發沖突。同時，還會檢查是否有缺失的引用需要提交，以能夠在與開發完全不同的環境中構建成功。

GeneXus發布了一個集成Jenkins的插件，需要注意，如果在GeneXus項目中要使用Jenkins，需要先安裝該插件，該插件能夠支持SCM和構建集成。

?

• 持續交付（CD）

CD是一種軟件開發策略，以使公司能夠盡可能快速、高效地給客戶發布新功能。

?

隨著持續交付概念的出項，也出現了pipeline概念。在軟件中，pipeline表示一系列排列的處理節點，每個節點的輸出都是下一個節點的輸入。這意味著pipeline將軟件的交付分解為幾個階段，每個階段都要驗證新功能的品質，以防止這些bug影響到用戶。Pipeline的目的是如果檢測到問題，則將在流程的每個節點反饋給開發團隊。

?

為了實現Pipeline的目的，我們必須將每個階段中能夠自動化的事情全部自動化。每個階段都必須能夠自動運行測試、供應、發布、安裝以及配置測試和階段環境，這樣才能保證開發人員能夠收到反饋。每次向Pipeline中添加代碼時，都必須定義驗證方法。當代碼通過各個階段時，都會被測試并反饋它的狀態信息。

?

• Docker容器發布

能夠讓您構建GeneXus應用的Docker鏡像，然后可以在端對端的CD Pipeline管理中的每個發布階段使用它們。

?

• GXtest 4.0

則通過采用為GeneXus開發人員、QE以及DevOps工程師設計的DevOps實踐和敏捷方法，以促進GeneXus社區使用和提高開發流程

---

?

總結

GeneXus一直在努力整合新的功能和技術，以讓團隊在接下來的幾年中，能夠使用各種不同的架構設計，其中包括微服務架構。

成功地應用微服務架構需要基于一個良好的自動化策略，我們相信GeneXus對于任何想使用微服務的公司是一個最佳選擇。微服務架構不僅僅是技術層面的選擇，同時還是一種不同的工作方式。而GeneXus將一直在這方面努力！

總結

以上是生活随笔為你收集整理的GeneXus与微服务那点事的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。