盤點構建微服務的那些工具和技術

本文從微服務體系結構開發的路徑，闡述從計劃、開發到測試的步驟，包括推薦使用到的一系列開源工具。

微服務是或微服務架構是一種軟體設計技術。是一種將應用程序構建為一系列松耦合服務的架構建風格。

它具有如下好處，比如通過簡化開發、測試和調試步驟來提高模塊化，從而讓開發者的生活變輕鬆，同時有助於持續集成和持續交付。本文將主要關注於Restful微服務。其實大多數工具都可以使用，無論你用哪幾種語言/體系結構 。

下面我們來看有哪些技術和可用的工具：

技術選型

任何編程語言都可以實現微服務，都可以使用不同的基礎設施。其主要的技術是微服務通信，包括同步，非同步，以用使用什麼協議，比如RESTful、Message服務等。

根據業務需求，我們需要選擇通信機制和協議。

微服務架構組件大致可分為如下：

1）API網關

2）負責均衡設備

3）服務發現

4）服務

5）資料庫或緩存

我們在本篇文章討論和組織使用不同的技術棧，供各位參考。

文檔

如同我們日常工作要記錄，每天睡前的日誌一般，任何微服務的體系結構和設計的重要性也是不言而喻的。我們對文檔的內容和樣式也會感到些許麻煩，值得慶幸的是，有很多模板可以供我們選擇：比如Arc42，一個免費開源的工具。除了生成結構化體系文檔外，如果要生成公開服務API文檔，則可以用Swagger，Apiary和ReDoc等工具，幫助我們生成公開服務的API。

開發

微服務的開發與任何其它類型的應用程序開發類似。任何開發者選擇的IDE，比如使用Eclipse或IntelliJ，還有其它文本編輯器，比如Atom、Sublime以及其它任意一種版本管理系統，無論是客戶端/伺服器模式的的SVN,Perforce或分散式系統如Git，Visual Studio Team Service，這些都可以用。

要構建和運行測試，我們需要有Maven、Ant等軟體項目管理工具。

要存儲生成的工件，可以用Nexus和Artifactory這些開源工具來完成。如果你需要讓構建和測試自動化，還有Jenkis和Bamboo這樣的自動化工具。

代碼審查

代碼Review是對任何編程語言編寫的源代碼進行審查。它的作用是為了檢查明顯的邏輯錯誤，滿足需求，確認最佳實踐等。

審查可以通過結對編程，非正式演練或正式審核流和來實現。有一個正式的審查流程是非常有價值的。

SmartBear協作工具支持全部的VCS/SCM工具，如Git，Subversion，Perforce和ClearCase等軟體，可以跑在Windows,Linux和Mac上。

Crucible是Atlassian公司提供的另一款支持VCS的流行工具，支持Git，SVN，CVS，Perforce等。

另外，還有Gerrit和Phabricator等免費和開源的代碼審查工具供你選擇。

除此以上，我們還應該重點關注代碼質量的持續檢查，通過靜態分析代碼來執行自動檢查，檢測錯誤、代碼異味等，我們可以使用像Sonarqube和PMD等工具來完成以上的需求。

日誌記錄

日誌記錄是任何服務都很重要的特性和功能之一。任何服務，我們都需要訪問日誌和服務日誌。如果我們只是存儲日誌，它不會增加任何價值，我們需要有一些機制來分析這些日誌來理解這些內容。

訪問日誌

在一般情況下，所有的應用程序和Web伺服器都會提供訪問日誌和錯誤日誌。訪問主要是跟蹤外部傳入的請求和參數、主機名、響應狀態等，錯誤日誌是用來記錄應用程序出錯或其它異常的錯誤內容。

服務日誌

可以在每個服務或基礎架構中存儲處理此類日誌。但是，需要從每個服務中生成日誌。在編寫日誌邏輯的同時，需要開發者考慮添加時間、源（類方法、類名稱等），錯誤的嚴重級別以及如消息、棧跟蹤等內容。這樣，當我們看到日誌句柄時，可以馬上知道哪個服務生成了日誌事件，以及生成該事件的服務位置。

然後，找到導致該問題的方法並執行。

重點，開發者需要一種將一系列事件追溯到源頭的方法，即使需要遍歷很多個服務。我們提供的解決方法是在請求進行日誌體系結構時，使用唯一的標識符，在請求完畢時也使用相同的標識符。

當一台伺服器處理多個不同類型的客戶端時，日誌輸出的格式是混合在一塊的。而MDC（Mapped Diagnostic Context - 映射診斷上下文）是用於區分來自不同源頭交叉的日誌輸出工具。

服務的內部日誌

維護服務的日誌，其生命周期具有如下優勢：它具有完全獨立於其它服務，可以選擇最適合的日誌策略。同時，它也有缺點：每個人服務都需要實現一個日誌策略，這些日誌是冗餘的，會增加各個服務之間修改日誌行為的複雜性。

基礎設施

在這種方法中，每個服務都將日誌發送給中央服務，中央服務知道如何處理，比如存儲或者向其它的日誌伺服器發送日誌。

查看日誌

簡單的查看日誌不是分析日誌的最佳解決方案。這裡有一些工具可以幫您更輕鬆的查看、搜索和分析日誌。Splunk和Kibana（由ELK Stack開發）是兩個查看日誌的著名工具。

Spring Cloud Sleuth是一個基於MDC（Mapped Diagnostic Context）概念的Spring Cloud項目，我們可以在日誌上下文中輕鬆提取想要的值，並顯示出來。

推薦使用Zipkin，它是一個分散式跟蹤系統，可幫助收集延遲等問題需要的時間數據。

測試

與單元測試一樣，集成測試需要涵蓋所有的場景，這非常重要。我們可以選擇從TDD到BDD或ATD的任何方法。像Randoop和Junit-tools這樣的工具可以幫助我們在編寫代碼後，生成Java單元測試用例。

可以使用Postman，Karate以及ZeroCode幫助我們開發集成測試。我們詳細介紹一下：

持續集成與持續交付（CI/CD）：CI與CD是實現微服務取得成功的之關鍵因素。沒有一個好的CI/CD流程，我們沒有辦法實現微服務承諾的敏捷性。

CI和CD的幾個關鍵流程：持續集成、持續交付和持續部署，可以用XebiaLabs的產品來實現持續交付和集成的漂亮視圖。

性能測試

除了單元測試和集成測試之外，我們還應該執行其他類型的測試，如壓力負載和性能測試。 Apache JMeter是一個非常不錯的工具，還有一個叫Blazemeter的一個工具，它允許將目標KPI設置為失敗標準並跟蹤一段應用的時間性能，然後將多個測試合併為一個運行，同時還生成精細的報告。

想要解決性能瓶頸等問題，比如確定內存泄漏還是了解線程等問題，還可以使用jProfiler等應用程序分析器。

監測

與微服務相關聯的最常見的挑戰之一就是監測。除了要知曉該服務是否正常響應外，還需要了解系統的其它部分，如資料庫，消息中間件等，監測這些重要組件是否工作正常。除此以外，開發者還希望取得各種指標，比如已經處理請求的數量、吞吐量、負載、出錯數量等。為了收集服務的單個操作的統計信息（指標），我們可以使用工具如Coda Hale/Yammer Jave Metrics Library或Prometheus客戶端。

收集完這些數據指標後，可以使用Grafana，Prometheus或AWS Cloudwatch等工具來監控。

到目前為止，與大家已經討論了目前各種可用的技術與工具。但是世界正在迅速變化，只知道現有技術已經不夠了，我們開發者需要超越今天的解決方案，並為未來發展做好準備。

開發者為了保持最新技術與工具，不斷成長。可以嘗試做的事情如下：

1、利用網路，印刷品和社交媒體；

2、參加學習與培訓；

3、積極實踐；

4、參與技術社區或會議

5、貢獻開源代碼。

祝各位周末愉快！

作者：Biplab Pal

編譯：洛逸

來源：https://dzone.com/articles/tools-and-techniques-to-build-microservices

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！