微服務架構 原來應用開發還可以這麼美好

單體應用這種傳統開發思維已經難以在新時代站住腳了。

一個簡單的應用會随着時間推移逐漸變大。在每次的sprint中，開發團隊都會面對新“故事”，然後開發許多新代碼。幾年後，這個小而簡單的應用會變成了一個巨大的怪物。

一旦你的應用變成一個又大又複雜的怪物，那開發團隊肯定很痛苦。靈活開發和部署舉步維艱，其中最主要問題就是這個應用太複雜，以至于任何單個開發者都不可能搞懂它。是以，修正bug和正确的添加新功能變的非常困難，并且很耗時。另外，團隊士氣也會走下坡路。

<a href="http://s4.51cto.com/oss/201710/28/0e08daadccfc7f2b4c9bd8decd443f37.jpg-wh_651x-s_3558418345.jpg" target="_blank"></a>

最後，單體式應用使得采用新架構和語言非常困難。比如，設想你有兩百萬行采用XYZ架構寫的代碼。如果想改成ABC架構，無論是時間還是成本都是非常昂貴的，即使ABC架構更好。是以，這是一個無法逾越的鴻溝。你不得不在最初選擇面前低頭。

相對于單體(Monolithic)應用而言，微服務是采用一組服務的方式來建構一個應用，服務獨立部署在不同的程序中，不同服務通過一些輕量級互動機制來通信，例如

RPC、HTTP 等，服務可獨立擴充伸縮，每個服務定義了明确的邊界，不同的服務甚至可以采用不同的程式設計語言來實作，由獨立的團隊來維護。

<a href="http://s4.51cto.com/oss/201710/28/4d37a4da4d382dec8fd99cf2925ba254.jpg" target="_blank"></a>

比喻來講，單點服務是把所有的東西放在一個大盒子裡，這個大盒子裡什麼都有。微服務更像是車箱，每個箱子裡包含特定的功能子產品和物品，所有東西可以很靈活地拆分出來。換言之，在單點服務中，所有的部件都在一個巨大的軟體包中。在微服務架構下，有很多獨立存在的小服務，通過

API 接口連接配接成龐大的系統。

表面上看來，微服務架構模式有點像SOA，他們都由多個服務構成。但是，可以從另外一個角度看此問題，微服務架構模式是一個不包含Web服務(WS-)和ESB服務的SOA。微服務應用樂于采用簡單輕量級協定，比如REST，而不是WS-，在微服務内部避免使用ESB以及ESB類似功能。微服務架構模式也拒絕使用canonical

schema等SOA概念。

<a href="http://s5.51cto.com/oss/201710/28/7f84b1781ac28a0031169ab9539e4418.jpg" target="_blank"></a>

微服務架構下，技術選型是去中心化的。每個團隊可以根據自身服務的需求和行業發展的現狀，自由選擇最适合的技術棧。由于每個微服務相對簡單，當需要對技術棧進行更新時所面臨的風險較低，甚至完全重構一個微服務也是可行的。當某一組建發生故障時，在單一程序的傳統架構下，故障很有可能在程序内擴散，形成應用全局性的不可用。在微服務架構下，故障會被隔離在單個服務中。若設計良好，其他服務可通過重試、平穩退化等機制實作應用層面的容錯。

使用微服務建構适合雲的新型應用是很有意義的，因為它讓你既利用了橫向擴充架構，也利用了縱向擴充架構，還額外得到API的組合，且在整個業務中可重複利用。可能在每一分鐘都在傳遞新服務，這樣你就會擁有一個靈活的且即時響應的應用程式平台，當然這一平台一直在不斷改進中，微服務架構也在前進着。

本文作者：張存

來源：51CTO