微服務架構詳解

微服務架構詳解

得益于2013年Docker的誕生，微服務概念及架構的推廣和落地變得更加的可靠和方便。在2016年及之前，微服務架構的討論更多的是活躍于互聯(lián)網(wǎng)企業(yè)及社區(qū)?，F(xiàn)如今，隨著Docker和微服務架構組件與Docker等相關技術的逐步成熟，微服務架構已然步入傳統(tǒng)企業(yè)及傳統(tǒng)行業(yè)。但是，程序員作為一個理性消費的群體，需要冷靜地思考，避免挖個大坑把自己給埋了。所以，我們需要冷靜地搞清楚：微服務（架構）是什么？它有什么優(yōu)勢劣勢？我們?yōu)槭裁葱枰捎梦⒎占軜?？如何讓老板接受這一新技術？如何落地？如何升級維護？等等……我們在過去7年智慧城市的建設過程中，研發(fā)和交付了很多的大型項目，踩過很多的坑，趟過很多的雷，深受傳統(tǒng)建設方法之苦，也深深被微服務架構帶來的好處所感動，我們也將在微服務架構這條路的繼續(xù)前行。在這里，將我們研發(fā)過程中的一些思考和心得分享給大家，供大家參考。也許，在不久的將來，軟件開發(fā)只需要組裝，不再需要從頭開發(fā)。什么是微服務架構？形像一點來說，微服務架構就像搭積木，每個微服務都是一個零件，并使用這些零件組裝出不同的形狀。通俗來說，微服務架構就是把一個大系統(tǒng)按業(yè)務功能分解成多個職責單一的小系統(tǒng)，并利用簡單的方法使多個小系統(tǒng)相互協(xié)作，組合成一個大系統(tǒng)。如果學科派一點，微服務架構就是把因相同原因而變化的功能聚合到一起，而把因不同原因而變化的功能分離開，并利用輕量化機制（通常為HTTPRESTfulAPI）實現(xiàn)通信。追本溯源，MartinFolwer對微服務架構的定義是：微服務架構是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，服務之間互相協(xié)調(diào)、互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間采用輕量級的通信機制互相協(xié)作（通常是基于HTTP協(xié)議的RESTfulAPI）。每個服務都圍繞著具體業(yè)務進行構建，并且能夠被獨立的部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，對具體的服務而言，應根據(jù)業(yè)務上下文，選擇合適的語言、工具對其進行構建

。（摘自王磊先生的《微服務架構與實踐》）對于我個人，我更喜歡一種延續(xù)性的解釋，微服務架構≈模塊化開發(fā)+分布式計算。不管微服務架構的定義怎么樣，都是在描述一個核心思想：把大系統(tǒng)拆分成小型系統(tǒng)，把大事化小，以降低系統(tǒng)的復雜性，從而大幅降低系統(tǒng)建設、升級、運維的風險和成本。順帶提一下，亞馬遜創(chuàng)始人JeffBezos在2002年就說過：所有團隊的模塊都要以ServiceInterface的方式將數(shù)據(jù)和功能開放出來。不這樣做的人會被炒魷魚。這才是思路超前的大牛。需要注意的是“微服務”與“微服務架構”是有本質區(qū)別的?！拔⒎铡睆娬{(diào)的是服務的大小，它關注的是某一個點。而“微服務架構”則是一種架構思想，需要從整體上對軟件系統(tǒng)進行通盤的考慮。ChrisRichardson說：“微服務”是一個很糟糕的名字，它導致開發(fā)人員創(chuàng)建了許多粒度很小的服務，每個服務擁有一個單獨的REST端點。不僅如此，這個名字還暗示了微服務在開發(fā)者心目中的重要位置。例如，人們會說“我們可以用微服務來解決這個問題”；我也看到了越來越多的“某某微服務框架”，而實際上，這些框架跟微服務架構不一定有太多聯(lián)系，它們只是簡單的Web框架。使用“微服務架構”這個名字會更恰當些。它是一種架構風格，它把一系列協(xié)作的服務組織成一個系統(tǒng)來支撐業(yè)務。常見的微服務組件及概念服務注冊，服務提供方將自己調(diào)用地址注冊到服務注冊中心，讓服務調(diào)用方能夠方便地找到自己。服務發(fā)現(xiàn)，服務調(diào)用方從服務注冊中心找到自己需要調(diào)用的服務的地址。負載均衡，服務提供方一般以多實例的形式提供服務，負載均衡功能能夠讓服務調(diào)用方連接到合適的服務節(jié)點。并且，節(jié)點選擇的工作對服務調(diào)用方來說是透明的。服務網(wǎng)關，服務網(wǎng)關是服務調(diào)用的唯一入口，可以在這個組件是實現(xiàn)用戶鑒權、動態(tài)路由、灰度發(fā)布、A/B測試、負載限流等功能。配置中心，將本地化的配置信息（properties,xml,yaml等）注冊到配置中心，實現(xiàn)程序包在開發(fā)、測試、生產(chǎn)環(huán)境的無差別性，方便程序包的遷移。API管理，以方便的形式編寫及更新API文檔，并以方便的形式供調(diào)用者查看和測試。集成框架，微服務組件都以職責單一的程序包對外提供服務，集成框架以配置的形式將所有微服務組件（特別是管理端組件）集成到統(tǒng)一的界面框架下，讓用戶能夠在統(tǒng)一的界面中使用系統(tǒng)。分布式事務，對于重要的業(yè)務，需要通過分布式事務技術（TCC、高可用消息服務、最大努力通知）保證數(shù)據(jù)的一致性。調(diào)用鏈，記錄完成一個業(yè)務邏輯時調(diào)用到的微服務，并將這種串行或并行的調(diào)用關系展示出來。在系統(tǒng)出錯時，可以方便地找到出錯點。支撐平臺，系統(tǒng)微服務化后，系統(tǒng)變得更加碎片化，系統(tǒng)的部署、運維、監(jiān)控等都比單體架構更加復雜，那么，就需要將大部分的工作自動化?，F(xiàn)在，可以通過Docker等工具來中和這些微服務架構帶來的弊端。例如持續(xù)集成、藍綠發(fā)布、健康檢查、性能健康等等。嚴重點，以我們兩年的實踐經(jīng)驗，可以這么說，如果沒有合適的支撐平臺或工具，就不要使用微服務架構。一般情況下，如果希望快速地體會微服務架構帶來的好處，使用SpringCloud提供的服務注冊（Eureka）、服務發(fā)現(xiàn)（Ribbon）、服務網(wǎng)關（Zuul）三個組件即可以快速入門。其它組件則需要根據(jù)自身的業(yè)務選擇性使用。微服務架構有哪些優(yōu)勢劣勢？要談優(yōu)勢，就一定要有對比，我們可以嘗試著從兩個維度來對比。一、微服務架構與單體架構的對比S/N對比點微服務架構單體架構結論1上手難度API接口調(diào)用數(shù)據(jù)庫共享或本地程序調(diào)用單體架構勝2.1開發(fā)效率（簡單項目）早期設計和溝通的工作量加大，隨著項目規(guī)模和時間的推移，效率變化不大早期工作量小，隨著項目規(guī)模和時間的推移，效率大幅度下降單體架構勝2.2開發(fā)效率（復雜項目）早期設計和溝通的工作量加大，隨著項目規(guī)模和時間的推移，效率變化不大早期工作量小，隨著項目規(guī)模和時間的推移，效率大幅度下降微服務架構勝3系統(tǒng)設計（高內(nèi)聚低耦合）每個業(yè)務單獨包裝成一個微服務，數(shù)據(jù)和代碼都從物理上隔離開來，實現(xiàn)高內(nèi)聚低耦合相對容易以包的形式對代碼進行模塊劃分，控制得當即可實現(xiàn)高內(nèi)聚。但最終都是在數(shù)據(jù)層面將整個系統(tǒng)耦合在一起微服務架構勝4系統(tǒng)設計（擴展性）獨立開發(fā)新模塊，通過API與現(xiàn)有模塊交互在現(xiàn)有系統(tǒng)上修改，與現(xiàn)存業(yè)務邏輯高度耦合微服務架構勝5需求變更響應速度各個微服務組件獨立變更，容易實施敏捷開發(fā)方法需要了解整個系統(tǒng)才可以正確修改，容易導致不相關模塊的意外失敗微服務架構勝6系統(tǒng)升級效率各個微服務組件獨立升級，上手和開發(fā)效率高，影響面小需要了解整個系統(tǒng)才可以正確修改，容易導致不相關模塊的意外失敗微服務架構勝7運維效率大系統(tǒng)被拆分為多個小系統(tǒng)，部署和運維難度加大，但可以利用DevOps等方式將運維工作自動化簡單直接單體架構勝8知識積累微服務組件可以在新項目中直接復用，包括前端頁面一般以共享庫的形式復用后臺代碼微服務架構勝9.1硬件需求（簡單項目）一個系統(tǒng)需部署多個微服務，需要啟動多個運行容器整個系統(tǒng)只需要一個運行容器單體架構勝9.2硬件需求（高要求項目）按需為不同業(yè)務模塊伸縮資源節(jié)點為整個系統(tǒng)分配資源，導致冗余微服務架構勝10.1項目成本（簡單系統(tǒng)）項目早期和后期，成本變化曲線平緩項目早期成本低，后期成本大單體架構勝10.2項目成本（復雜系統(tǒng)）項目早期和后期，成本變化曲線平緩項目早期成本低，后期成本大微服務架構勝11非功能需求為單獨的微服務按需調(diào)優(yōu)，甚至更換實現(xiàn)方式和程序語言為整個系統(tǒng)調(diào)優(yōu)，牽一發(fā)而動全身微服務架構勝12職責、成就感擁有明確的職責劃分，主人翁意識和成就感加強，容易形成自組織型團隊職責不明確，容易產(chǎn)生扯皮行為微服務架構勝13風險大系統(tǒng)被拆分為小系統(tǒng)，風險可被控制在小系統(tǒng)內(nèi)，但也引入了各小系統(tǒng)之間的交互風險系統(tǒng)是一個整體，一榮俱榮，一損俱損微服務架構勝

結論：對于對于簡單項目來說，單體架構5勝8敗。簡單項目來說，單體架構5勝8敗。（優(yōu)勢項：開發(fā)效率、上手難度、運維效率、硬件需求、項目成本；劣勢項：系統(tǒng)設計（高內(nèi)聚低耦合）、系統(tǒng)設計（擴展性）、需求變更響應速度、系統(tǒng)升級效率、知識積累、非功能需求、職責、成就感、風險）對于復雜項目來說，單體架構2勝11敗。（優(yōu)勢項：上手難度、運維效率；劣勢項：硬件需求、項目成本、開發(fā)效率、系統(tǒng)設計（高內(nèi)聚低耦合）、系統(tǒng)設計（擴展性）、需求變更響應速度、系統(tǒng)升級效率、知識積累、非功能需求、職責、成就感、風險；）二、微服務與共享庫的對比注：這里以使用方自行安裝微服務為場景來比較。這里的共享庫指的是像Java中的公共jar依賴。S/N對比點微服務共享庫結論1易用性整體安裝+API調(diào)用共享庫引用+本地調(diào)用平手2程序耦合度微服務為完整的業(yè)務邏輯單元，通過API的形式為其它模塊提供服務在使用方的源代碼中引用共享庫的類和方法平手3版本升級單獨升級，其它模塊無感知修改源代碼，升級使用方的代碼版本，例如pom.xml,build.gradle微服務架構勝4Bug修復單獨升級，自動生效修改源代碼，升級使用方的代碼版本，例如pom.xml,build.gradle微服務架構勝5非功能需求為單獨的微服務優(yōu)化或擴縮容；在需求更高的情況下，可以重新設計或使用不同的程序語言為整個業(yè)務系統(tǒng)優(yōu)化或擴縮容，共享庫的程序語言必須和業(yè)務系統(tǒng)的程序語言相同微服務架構勝6復用程度可以復用從前端頁面到后臺數(shù)據(jù)庫的整個業(yè)務邏輯和代碼可以復用后臺代碼和數(shù)據(jù)庫，但程序語言需要和業(yè)務系統(tǒng)保持一致微服務架構勝什么場景需要用微服務架構？看了上面的比較，微服務架構可以說是以壓倒性的優(yōu)勢勝過單體架構和共享庫，會讓人產(chǎn)生一種錯覺，微服務架構就是軟件開發(fā)中的銀彈。但是，正如大家所了解的，軟件研發(fā)是一個系統(tǒng)工程，它沒有銀彈，不能夠一招鮮吃遍天。正如當年的CMMI和敏捷方法一樣，敏捷雖好，但它不一定能適用于所有的場景，它對組織環(huán)境、團隊氛圍、溝通方式、技術能力這些都是有一些要求的，如果用不好，反而會帶來一些負面影響。那么，我們什么時候需要采用微服務呢？從我個人的經(jīng)驗來看，我認為有三種場景可以考慮使用微服務。規(guī)模大（團隊超過10人）業(yè)務復雜度高（系統(tǒng)超過5個子模塊）需要長期演進（項目開發(fā)和維護周期超過半年）這里借一張圖來說明：橫軸是復雜度，縱軸是生產(chǎn)效率。從生產(chǎn)效率的角度來講，在兩條曲線的交叉點之前，單體架構是占優(yōu)勢的，過了交叉點之后，單體架構的生產(chǎn)效率將大幅度下降。所以很多專家和同行朋友都說，我們可以在開始的時候先使用單體架構，當業(yè)務發(fā)展到一定程度的時候，再重構成微服務架構。對于這一點，我是持保留意見的，因為在實踐中，架構改造的難度還是很大的，會有一些問題，例如：客戶或業(yè)務部門是否給我們這樣的時間窗口？這段時間的研發(fā)經(jīng)費是否有出處？項目負責人或技術團隊是否有主動的意愿進行架構升級？項目負責人或技術團隊是否愿意為架構升級帶來的不穩(wěn)定風險負責？我們常常聽到的一句話是：暫時先這樣，等我們沒這么忙的時候，再來優(yōu)化一下。但是，絕大多數(shù)情況下，這一天從來沒有出現(xiàn)過。再想想年初，我們的私有云平臺經(jīng)過2年多的發(fā)展，已經(jīng)包含了容器服務平臺（PaaS）、API網(wǎng)關、監(jiān)控平臺、定時任務平臺、數(shù)據(jù)庫管理、用戶權限管理等等十多個基礎模塊，也包含了一些為上層應用服務提供的日志服務、緩存服務、消息服務等等。并且，部署到了二十多個客戶的生產(chǎn)環(huán)境里?？杀氖?，我們支撐了很多的業(yè)務系統(tǒng)的微服務化，但平臺本身任然是一個單體系統(tǒng)。我們也深深地感受到了平臺往前發(fā)展的阻力：很多時候，客戶需要的不是一個大而全的平臺，他們希望按他們的意愿采購需要的模塊。新人進入團隊后，從熟悉到動手產(chǎn)出的時間偏長。其它研發(fā)團隊有一些比較好的組件能滿足平臺產(chǎn)品的需求，卻不能直接拿來用。兩個不同的模塊之間產(chǎn)生了不該出現(xiàn)的耦合關系，導致意想不到的Bug。所以，春節(jié)過后，大家開了一個會，決定將平臺微服務