微服務(wù)架構(gòu)詳解

微服務(wù)架構(gòu)詳解

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

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

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