微服務對程式設計師職場進階幫助有多大

微服務microservice

微服務是指提供單個業務功能的服務，從技術角度看就是一種小而獨立的處理過程，類似流程概念，能夠自行單獨啟動或銷燬，擁有自己獨立的資料庫。

一個複雜軟體架構是由很多這樣小而獨立執行(有自己的埠)微服務組成，這些獨立處理元件之間通訊是透過與語言無關的API進行，簡單協議有同步性質的RMI/RPC和 RESTful Web Services，非同步的訊息推送和Reactive方式。

這些模組化的方式能夠使得公司將專案分解分散到多個開發團隊，跨不同業務部門，提供非常充分的靈活性，幫助提高專案的生命週期，加快專案開發完成效率。

每個微服務元件都有自己分配的儲存 記憶體和CPU資源，這就使得硬體利用更加易於最佳化和跟蹤，特別是在基於雲的Pass環境，開發團隊可以使用他們喜歡的技術，任何語言都可以，只要確保微服務之間是可互動的，能夠最終組合起最後的應用。

當管理複雜性會因為採取微服務架構而降低，通常更新其中一個微服務元件不會引起連鎖反應，因為微服務之間是松耦合的。

目前使用微服務的企業有：Netflix Twitter Amazon Web Services (AWS), Google, eBay等。

因為有很多應用和服務部署在基於雲主機的環境中，微服務架構將會嚴重依賴容器技術，容器隔離了微服務處理過程，將一個應用切分為一個個小的例項，這些容器中的小例項有自己的埠和虛擬化環境。

廣泛使用的容器技術是Docker, 一種基於Linux的開源實現，由很多軟體公司支援如 Canonical, Red Hat,和Parallels. PaaS服務支援包括Google App Engine, Red Hat Open Shift,和VMware的 Cloud Foundry,。

微服務架構不只是傳統服務變微變小。微服務兩個顯著特點是：

微服務本身是無狀態的;

微服務之間很少可變共享。

可以設想一下，如果微服務之間可以共享，那麼帶來兩個問題：微服務團隊之間需要合作，因為共享的是一個統一資料庫，如果這種共享沒有帶來溝通成本，沒有破壞一個團隊就能搞定的宗旨，那麼這種共享資料庫也是可以考慮，但是這種情況很少，大部分團隊因為共享問題破壞了獨立性;再者，微服務如果使用Docker分別打包在一個容器中，這些容器可能是跨不同基礎設施部署，部署方式很靈活，是一種cloud native應用，而共享資料庫屬於底層基礎設施，顯然提高了部署難點。

另外，傳統服務之間通訊無論是RPC/RMI或是Http/RESTful都是同步的，而微服務之間通訊最好是非同步的或reactive的，也就是非同步的。根據FLP不可能原理，網路預設是不可靠的，RPC在一旦發生網路堵塞會連環爆炸，事後監控並不能根本解決這個問題，需要從CAP定理角度進行平衡設計，引入事件驅動或Pub/Sub訊息方式能在提高網路容錯性的同時，保證資料最終一致性，柔性事務是微服務環境的主要選擇。

傳統服務變成鐵板一塊經常是因為事務處理要求，某個服務方法的程式碼很多，需要塞在同一個事務邊界內，雖然這帶來了高一致性的，但是擴充套件性比較差，因為同一個事務邊界內的動作無法分離到幾個微服務中，因此，使用微服務必須積極擁抱最終一致性，對分散式系統以及CAP定理有一定理解。當然，這些都是必須有多個微服務呼叫的情況下才需要考慮，由於微服務粒度小且專一，可以透過組合替代共享繼承的思路，容忍程式碼有一定的重複性。

一個微服務架構需要具備以下條件:

基礎監視 測量和健康檢查

分散式日誌 跟蹤

針對每個服務，不只是隔離程式碼，還需要在構建+測試+打包+提交整個環節隔離。

能清晰定義每個服務的上下游、編譯時間和執行依賴。

掌握如何構建、暴露和維護好的API和合約。

需要尊重b/w和f/w相容性，即使你可能不同時是你生產的服務的消費者。

好的單元測試和更具有可讀性

注意微服務與模組和庫包區別，以及分散式整體型monolith, 協同版本釋出，資料庫驅動繼承的區別。

知道基礎設施的自動化

需要基於CI/CD持續整合/持續遞交的基礎設施

服務劃分：

根據業務能力界定服務的範圍

根據領域驅動設計中子域的概念界定服務的範圍

通訊模式：

使用基於RPC的同步通訊方式

使用非同步訊息進行服務間通訊

外部API：

API 閘道器(API gateway) - 為每一類客戶端提供一個訪問服務的獨特介面

服務前端的後端(Backend for front-end) - 為每一類客戶端都提供一個獨立的 API 閘道器

資料管理：

每個服務都擁有它私有的資料庫特介面

服務之間共享同一個資料庫

使用事件來維護服務間的資料一致性 事件溯源/CQRS

運維監控：

服務的發現：透過第三方模組來進行服務例項資訊到服務登錄檔的註冊過程

分散式追蹤(Distributed tracing)new - 在服務程式碼中針對每一個外部訪問，都分配一個唯一的服務識別符號，並在跨服務訪問時傳遞這個識別符號以供追蹤分散式引發

斷路器(Circuit Breaker) - 當遠端服務返回的故障率超過一定的閥值時，客戶端代理(比如 API 閘道器)對遠端服務的呼叫將立刻返回失敗的資訊。

作者：JavaSpring高階進階

來源：今日頭條

知識的掌握對我們學習至關重要，如果你想要做一名出色的程式設計師，那麼就從鄭州達內微服務方面瞭解開始吧