一、前言 近些年微服務是越來越應用廣泛了，去年的時候丹姐出去面試，面試官問過她有沒有用過微服。當時自己還沒有建立一個服務的概念 ，瞬間懵逼了。但是後來回想，現在自己的系統也是釋出了很多的服務，每個服務都算是一個微服務。

二、什麼是微服務 微服務（Microservice）雖然是當下剛興起的名稱，但是本質上來說，微服務並非什麼新的概念。實際上，很多SOA實施程度比較好的公司，已經在使用微服務了。只不過，他們自己使用，並不介意是否有一個時髦的名詞來描述表示SOA已經發展到了微服務。

微服務其實是服務化思路的一種最佳實踐方向。之所以交微服務，是與之前的服務化思路和實踐相比較而來的。早些年的服務實現的思路是將很多功能開發並交付都打包到一個很大的服務單元（Monolith），而微服務實現思路更加趨向單一，服務單元小型化和微型化。

所以，在思路和理念上，微服務就是要倡導大家儘量將功能進行拆分，將服務粒度做小，每個服務可以單獨的承擔對外服務的職責，沿著這個思路開發和支付的軟體服務實體就叫做“微服務”。

您可能會問，原來將很多功能打包到一個很大的服務單元進行交付不能滿足需求嗎？

實際上，並非原來的服務“大一統”（Monolish）實踐不能滿足要求，也不是不好，只是他有自己存在的合理場景。對於Monolish服務來說，如果團隊不大，軟體複雜度不高，那麼，使用Monolish的形式進行服務化治理是比較合適的。

但是，隨著軟體系統的複雜度持續飆升，軟體交付的效率要求更高，投入的人力等資源越來越多。為了減輕複雜，我們自然會將專案按照要開發的功能拆分為不同的專案，負責不同研發服務的研究人員，可以並行操作。

三、微服務帶來的好處

• 獨立、獨立、獨立 每個服務基本上都是獨立的專案，帶來的明顯的好處，第一個就是可拓展性。微服務可以快速的新增服務叢集的例項，提升整個微服務叢集的服務能力，而在傳統的模式下，為了提升服務能力，很多時候必須強化和拓展單一節點的服務能力來完成。如果單個節點服務能力已經達到極限，再尋求拓展的話，得從硬體整體下手。

• 多語言生態 微服務的提供者既可以使用java或者GO等靜態語言完成微服的開發和交付，也可以使用python或者Ruby等動態語言完成微服務的開發和交付 四、微服務會帶來哪些挑戰 微服務給我們帶來的並非只有好處，還有一些挑戰。

• 服務之間的治理

• 硬體設施負載增加

• 增加一種語言生態用於微服務的開發和交付，是否需要重新搭建一套研發測試環境。

五、小結 微服務話雖然是當下的流行趨勢，但是並非任何場景都合適，我們要慎重考慮“大一統”和微服務架構。而且一旦確定選擇了微服務化之路，那麼就應該圍繞團隊和組織的主要語言生態以及微服務方向積極搜素高效的開發和交付方式。