什么是微服務架構

簡單地說，微服務是系統(tǒng)架構上的一種設計風格， 它的主旨是將一個原本獨立的系統(tǒng)拆分成多個小型服務，這些小型服務都在各自獨立的進程中運行，服務之間通過基于HTTP的RESTful API進行通信協(xié)作。被拆分成的每一個小型服務都圍繞著系統(tǒng)中的某一項或一些耦合度較高的業(yè)務功能進行構建， 并且每個服務都維護著自身的數(shù)據(jù)存儲、業(yè)務開發(fā)、自動化測試案例以及獨立部署機制。

微服務架構的優(yōu)缺點

微服務的優(yōu)點

·每個微服務都很小，這樣能夠聚焦一個指定的業(yè)務功能或業(yè)務需求。

·微服務能夠被小團隊單獨開發(fā)，這個小團隊是2到5人的開發(fā)人員組成。

·微服務是松耦合的，是有功能意義的服務，無論是在開發(fā)階段或部署階段都是獨立的。

·微服務能使用不同的語言開發(fā)，如Java、Python、PHP、C#等。

·微服務允許容易且靈活的方式集成自動部署，通過持續(xù)集成工具，如Jenkins, Travis CI等工具。

·一個團隊的新成員能夠更快投入生產(chǎn)。

·微服務易于被一個開發(fā)人員理解，修改和維護，這樣小團隊能夠更關注自己的工作成果。無需通過合作才能體現(xiàn)價值。

·微服務允許你利用融合最新技術。

·微服務只是業(yè)務邏輯的代碼，不會和HTML,CSS 或其他界面組件混合。

·微服務能夠即時被要求擴展。

·微服務能部署中低端配置的服務器上。

·易于和第三方應用系統(tǒng)集成。

·每個微服務都有自己的存儲能力，可以有自己的數(shù)據(jù)庫，也可以有統(tǒng)一數(shù)據(jù)庫。

微服務的缺點

·微服務架構可能引入過多的操作；

·需要提高DevOps應用技巧；

·對于開發(fā)和運維帶來一定的挑戰(zhàn)，需要付出雙倍的努力；

·分布式系統(tǒng)比單體應用架構復雜，且難以管理；

·對于故障診斷比較難，分布式部署跟蹤比單體架構復雜；

·當服務數(shù)量增加，管理復雜性增加。

微服務架構在工業(yè)應用上的實戰(zhàn)

下面以格創(chuàng)東智在某工業(yè)生產(chǎn)行業(yè)客戶進行了微服務架構的實際落地案例進行說明。目前該公司的微服務架構如下圖所示。

該公司擁有MES、EDA、RPT、SPC、OEE、FDC等應用，其中查詢、分析類應用已經(jīng)移植到微服務架構，使用的是Spring Cloud。

以RPT系統(tǒng)為例，使用SpringCloud之后，新增報表只需要開發(fā)有關業(yè)務邏輯的代碼，其他配置、權限及校驗代碼都由微服務架構代勞，其開發(fā)和測試部署相較之前更加快捷，而且融合了Python技術，在某些特定場景下，系統(tǒng)運行效率也有可觀的改善。

在異常分析系統(tǒng)中，之前使用的是Spark MLlib，但是在預測產(chǎn)品異常方面，Python的Keras效果更佳，在導入微服務架構后，可以很方便的使用Scala和Python的“混合”架構，系統(tǒng)的分析準確率得到了提升。

在移植過程中遇到了微服務的“邊界”問題，在我們進行微服務架構設計和改造過程中，一個不可避免的問題是如何確定服務邊界、如何進行服務識別，微服務的劃分粒度究竟如何確認。我們可能會聽到，服務既不能太大，也不能太小，當然這是一個籠統(tǒng)的概念。那么，問題來了，究竟多大是大，多小是小。

一個設計良好的服務應包含以下五個特征：

特征一：服務不與其他服務共享數(shù)據(jù)庫

特征二：服務應包含盡可能少的數(shù)據(jù)庫表

特征三：一個服務要么包含完整的業(yè)務含義，要么是放之四海皆通用的公共服務。

特征四：一個良好的服務應首先確保其數(shù)據(jù)可用性。

特征五：在一個業(yè)務系統(tǒng)中，一個服務只能是并且唯一的可信來源。

MES系統(tǒng)和EDA系統(tǒng)這一類與生產(chǎn)強相關的應用，業(yè)務邏輯復雜，耦合性強，進行服務“拆分”很難符合以上5個特征。所以暫時無法對其進行“拆分”。

綜上所述，微服務架構比較適合制造業(yè)應用中查詢、分析類應用，在生產(chǎn)控制這一類與生產(chǎn)強相關的應用上的作用還有待挖掘。