微服務是什麼

      通常開發程序完成後會打包並部署為一個個具體的程式。每個具體的格式依賴於相應的程式語言和框架。例如，Java程式通常會被打包為WAR格式，部署在Tomcat，這種程式開發風格很常見，只需要簡單運行此程式，用些工具連結UI就可以完成端到端測試。在早期這類程式運行的都很好，但一個簡單的程式會隨著時間推移逐漸變大。幾年後，這個小而簡單的程式會變成了一個巨大的怪物。一旦你的程式變成一個龐大而又複雜的怪物，那開發團隊肯定很痛苦。其中最主要問題就是這個程式太複雜，以至於任何單個開發者都不可能搞懂它。因此，修正bug和正確的添加新功能將變的非常困難，並且很耗時。當一個程式越大，啟動時間就會越長。那麼大部分時間就要在等待中渡過，生產效率會受到極大影響。

 

另外，一個程式在不同模組發生資源衝突時，擴展將會非常困難。程式的另外一個問題是可靠性。當所有模組都運行在一個進程中，任何一個模組中的一個bug，將會有可能弄垮整個進程。除此之外，因為所有程式實例都是唯一的，這個bug將會影響到整個程式的可靠性。

 

    隨著軟體的複雜度越來越高，越大型的軟體，維護的成本也持續增長，為了因應不斷攀升的維護成本，把單體式的系統，拆解成多個獨立的小服務，透過API互相溝通，這一種軟體架構風格，就稱作微服務。在設計時，以業務功能為主進行切割，將一個個業務功能都獨立實作成能自主執行的個體，再利用相同的協定，把應用程式所需要的服務彼此串接起來，形成一個完整的應用程式。

 

 

單體式的系統帶來的問題

      單體式的系統在規模比較小的情況下工作情況良好，但是隨著系統規模的擴大，它暴露出來的問題也越來越多。

1.       複雜性逐漸變高，有的程式有幾十萬行代碼，各個模組之間區別比較模糊，邏輯比較混亂，代碼越多複雜性越高，越難解決遇到的問題。

2.       技術債逐漸上升，公司的人員流動是再正常不過的事情，如果疏於代碼質量的控管，導致留下來很多坑，由於單體項目代碼量龐大的驚人，留下的坑很難被發覺，這就給新來的員工帶來很大的煩惱，人員流動越大所留下的坑越多，也就是所謂的技術債越來越多。

3.       部署速度逐漸變慢，單體架構模組非常多，代碼量非常龐大，導致部署項目所花費的時間越來越多，啟動幾次項目一天的時間就過去了，留給開發的時間就非常少了。

4.       阻礙技術創新，比如以前的某個項目使用struts2寫的，由於各個模組之間有著千絲萬縷的關係，代碼量大，邏輯不夠清楚，如果現在想用spring mvc來重構這個項目將是非常困難的，付出的成本將非常大，所以不得不硬著頭皮繼續使用老的struts架構，這就阻礙了技術的創新。

5.       無法按需求伸縮，比如說A模組是CPU密集型的模組，而B模組是IO密集型的模組，假如我們要提升B模組的性能，比如加大記憶體、增加硬碟，但是由於所有的模組都在一個架構下，因此我們在擴展B模組的性能時不得不考慮其它模組的因素，因為我們不能因為擴展某個模組的性能而損害其它模組的性能，從而無法按需求進行伸縮。

 

 

微服務由來

微服務於2014由Martin Fowler與James Lewis共同提出，微服務架構風格使用一套小服務來開發單個程式的方式，使用輕量級通信機制，通常是HTTP API，這些服務基於業務能力構建，使用不同的編程語言實現，以及不同數據存儲技術，並保持最低限度的集中式管理。

左圖：整體式程式將所有功能放到一個進程中，通過複製整個程式到多台服務器來實現拓展

右圖：微服務架構將功能的每個元素放置到分離的多個服務進程中，通過將不同的服務分佈於不同的服務器，並按照需求複製服務的方式實現拓展

 

 

優勢

l   可提升軟體交付頻率，代表著新的功能可更快的上線，因微服務自身架構的特性，在微服務架構中軟體的變更，只會影響到本身的模組，較不會影響到另一個不相關的系統模組，且可以很獨立的控制部署週期。而整體式系統因為其自身容易隨著時間越來越大，越來越複雜，無論內部如何的模組化，各個模組還是在同一個系統，在大型身軀下會降低系統交付速度和提高其風險，當系統的程式碼越大時，就會感覺到系統建置時間會越來越長。

 

l   可自主性。 可針對系統的需求或效能考量，選擇合適的技術和工具，可避免選擇一體適用的做法，像是可以選擇合適的開發語言或Database技術來使用。

 

l   可利用性。 藉由重複使用來開發不同的裝置平台例如 Web、Mobile 和各種應用平台，避免重複造輪子。

 

l   可隔離性。 如果某服務發生異常，而異常並未有其他連鎖反應，那麼可根據業務來區隔問題，維持其餘系統的運作。如果是整體式系統，就有可能導致整個系統掛點。

 

 

微服務所面臨的挑戰

u 微服務應用是分佈式系統，由此會帶來複雜性，也意味著開發者需要考慮網絡延遲、容錯、消息序列化、不可靠的網絡、異步、版本控制、負載等。

 

u 在很多服務中可能都會使用到同一個功能，而這一功能點沒有足夠大到提供一個服務的程度，這個時候可能不同的服務團隊都會單獨開發這一功能，導致重複的業務邏輯。

 

u 微服務中每個服務都能夠有自己的資料庫，最終必須處理資料一致性的問題。

 

u 測試方式變得更為複雜

 

 

 

SOA與微服務

在大多情況下，每個系統和ESB之間，只需要定義一個訪問方法，一個接口。如果這樣，像上面的圖一樣，有8個系統，就會有16個接口（1個方向1個）需要被創建、維護、管理和關注。如果沒有ESB，就需要56個接口需要去思考和處理。（假設每個系統都需要跟其他系統對話）

 

SOA關注的是服務重用，微服務在關注服務重用的同時，也同時關注快速交付，微服務不再強調傳統SOA架構裡面比較重的ESB企業服務總線，把所有的邏輯包括路由、消息解析等放在服務內部，去掉龐大的ESB，服務之間使用較輕量的通信方式，是比SOA更徹底的拆分。