一、前言
作者接觸微服務也好久時間了，從零開始構建公司產品的微服務化，目前逐步成型穩定。計劃在接下來的時間裏，把微服務架構下項目的實踐，分門別類的總結匯總，圍繞“微服務架構下的核心話題”，與大家分享，希望能夠給大家在微服務中帶來幫助，助力你更好的瞭解它，避免走不必要的彎路。
在接觸任何一個新鮮事物初期時，你一定有必要了解它，知道它能給你帶來什麼、有哪些優勢、哪些弊端，最終要搞明白它是否合適你，再決定是否使用它。技術更是如此，這也就是常常所說的技術選型、架構選型，更是作爲一個架構師必須衡量考慮的。在當前技術不斷革新的趨勢下，每天可能都有新的概念、新的體系、新的技術(框架)出現，微服務的出現，紛紛被衆多技術人、公司所追捧，彷彿給傳統項目的重構、新項目的研發帶來了便捷、萌發了希望，但大家都真的瞭解它麼？
在微服務架構下，各類項目也順勢崛起，作爲技術人，貌似不會微服務，都有些不好意思。(調侃一下而已)
就以下兩個方面，帶你更好的瞭解微服務架構體系，明白爲什麼在微服務架構下各類項目的順勢崛起。
- 什麼是微服務
- 爲什麼要使用微服務
二、什麼是微服務
微服務的概念，最早由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家族就是一類典型的代表，後續文章將在詳細介紹在微服務中的技術選型。
正因爲微服務上述這些特性，使得在微服務的影響下，各類項目順勢崛起，爲各類中小型軟件公司帶來了希望。
參考：
1.https://microservices.io/index.html
2.https://www.cnblogs.com/beanbag/p/9911452.html
歡迎微信掃碼下面二維碼，關注微信公衆號【程序猿技術大咖】，進行更多交流學習！
