微服務架構下各類專案的順勢崛起

　　一、前言

　　作者接觸微服務也好久時間了，從零開始構建公司產品的微服務化，目前逐步成型穩定。計劃在接下來的時間裡，把微服務架構下專案的實踐，分門別類的總結匯總，圍繞“微服務架構下的核心話題”，與大家分享，希望能夠給大家在微服務中帶來幫助，助力你更好的瞭解它，避免走不必要的彎路。

　　在接觸任何一個新鮮事物初期時，你一定有必要了解它，知道它能給你帶來什麼、有哪些優勢、哪些弊端，最終要搞明白它是否合適你，再決定是否使用它。技術更是如此，這也就是常常所說的技術選型、架構選型，更是作為一個架構師必須衡量考慮的。在當前技術不斷革新的趨勢下，每天可能都有新的概念、新的體系、新的技術(框架)出現，微服務的出現，紛紛被眾多技術人、公司所追捧，彷彿給傳統專案的重構、新專案的研發帶來了便捷、萌發了希望，但大家都真的瞭解它麼？

　　在微服務架構下，各類專案也順勢崛起，作為技術人，貌似不會微服務，都有些不好意思。(調侃一下而已)

　　就以下兩個方面，帶你更好的瞭解微服務架構體系，明白為什麼在微服務架構下各類專案的順勢崛起。

　　什麼是微服務

　　為什麼要使用微服務

　　二、什麼是微服務

　　微服務的概念，最早由Martin Fowler與James Lewis於2014年共同提出，在近幾年才走入大家的視線，引起關注。首先，我們看一下Martin Fowlern在《Microservices》一文是如何給微服務下定義的：

　　In short, the microservice architectural style  is an approach todeveloping a single application as a suite of small services, each running inits own process and communicating with lightweight mechanisms, often an HTTPresource API. These services are built around business capabilities andindependently deployable by fully automated deployment machinery. There is abare minimum of centralized management of these services, which may be writtenin different programming languages and use different data storage technologies.

　　如Martin所言，將單體應用拆分為一組微小的服務，每個微小的服務單獨執行，服務間可透過如RESTful API這樣輕量級的接，這些服務以業務能力為核心，用自動化部署機制獨立部署。這些服務可以用不同語言開發，用不同技術來儲存資料。

　　以我理解來看，微服務架構的特性如下：

　　將單體應用進行解耦，按照一定方式(如：業務分類等)拆分為多個微小的服務，微服務間相互互動以完成實際業務流。

　　微服務間通訊方式更輕量化，如：RESTful。

　　各微服務支援單獨部署、單獨執行。

　　各微服務的開發語言不限，可交叉選擇不同語言。

　　簡單來說，微服務其實是從早期的CORBA、COM+等技術，到後來的SOA、RESTful架構，是一種分散式計算思想的延續。

　　具體來說，把單體應用拆分為一個一個微小服務，而這些微小服務又不依賴任何伺服器，使其可以透過自動化方式獨立部署，每個服務可以執行在自己的程式或Docker容器中，透過輕量的通訊機制，能夠基於業務能力快速構建，動態擴容，實現集中化管理的系統架構。

　　三、為什麼要使用微服務

　　伴隨著網際網路系統的爆發、系統的多樣化以及系統分層切塊的演變，系統變得越來越複雜，呼叫鏈也越來越複雜，傳統單體系統已經無法再支撐這種變化，因此微服務的思想也就順應而來，用來解決這種現狀。

　　傳統的單體系統，企業往往需要耗費幾個月乃至幾年，才能落地一個系統，達到上線的標準。這就給一些小公司的前進帶來了瓶頸，沒人敢輕易研發、重構一個新的產品，但在現在網際網路日益變革的時代，不得不大膽向前嘗試，力爭在最短的時間內完成一個新的產品。在網際網路時代常常要求一週內完成一個功能或小專案，這種不斷伸縮的業務形態，不斷要求縮短的開發週期，使得我們需要在系統的擴充套件、伸縮、減低相互影響上做出文章。

　　那麼，怎麼才能達成系統的擴張呢？在Microservice Architecture一文中提到，我們需要將服務進行拆分，拆分為前置服務和業務服務，並在前端新增SLB(Server Load Balance)，用一組相同的前置服務組成及其來提供服務。

　　而減低各模組、各業務的相互影響，就需要將單體系統按照模組或業務進行拆分，以此來減低其耦合性。

　　上面提及到問題，在微服務架構下，給出了一些完美的解決方案。

　　1.模組服務化

　　單體系統，團隊在多人協作開發時，往往會存在因程式碼、設計思路等差異而造成相互影響，相互等待對方的現狀，而且系統的龐大也給後期維護帶來諸多不便。而微服務最突出的一個特性“解耦”，恰恰解決了這種問題，讓系統更加輕量化，便於多人協同開發而互不依賴。

　　2.獨立部署，靈活擴充套件

　　傳統的單體架構是以整個系統為單位進行部署，而微服務則是以每一個獨立服務（例如：使用者服務，檔案服務等）為單位進行部署。用下圖能夠更好的體現：

　　左邊是單體架構的叢集，右邊是微服務叢集 。

　　各個服務都是獨立部署，可以根據各自服務的特點進行適當調整，即：根據服務的吞吐量、壓力等不同的指標，分別給出不同的部署方案(部署策略)，使得資源更加充分合理的使用。這種靈活部署只有微服務架構才能實現。

　　3.資源的有效隔離

　　這是微服務設計的原則之一，就是每一個微服務擁有自己獨立的資料來源，假如微服務A想要讀寫微服務B的資料庫，只能呼叫微服務B對外暴露的介面來完成。這樣有效避免了服務之間爭用資料庫和快取資源所帶來的問題。

　　如果採用Docker部署，則每一個微服務例項在Docker容器上執行，更加完美的實現了伺服器資源（記憶體、CPU資源等）的有效隔離 。

　　4.多語言，多選擇

　　在微服務架構下，因為有了模板服務化，各模組互不依賴的特點，對開發語言的選擇就沒有統一的要求，完全可以根據企業技術人員情況，不同模組的特點來選擇不同的開發語言，讓開發變得更加多樣化。

　　5.團隊組織架構的靈活

　　微服務架構設計的思想，改變了原有的企業研發團隊的組織架構。傳統的研發組織架構是水平架構，前端有前端的團隊，後端有後端的團隊，DBA有DBA的團隊，測試有測試的團隊。

　　而微服務架構的設計思想對團隊的劃分有了一定的影響，使得團隊組織架構的劃分更傾向於垂直架構，比如使用者業務是一個團隊來負責，支付業務是一個團隊來負責。這種團隊組織架構，也更好的協同來完成一個系統。

　　當然，上述這種垂直劃分只是一個理想的架構，實際在企業中並不會把團隊組織架構拆分得這麼絕對。

　　6.元件/框架多樣化、成熟化

　　伴隨著微服務出現，不斷膨脹，各類技術元件、框架應用而生，為我們的開發降低了成本，加快了專案的開發週期。這些元件/框架紛紛落地投產，變得更加的穩定成熟。Spring Cloud家族就是一類典型的代表，後續文章將在詳細介紹在微服務中的技術選型。

　　正因為微服務上述這些特性，使得在微服務的影響下，各類專案順勢崛起，為各類中小型軟體公司帶來了希望。