前言
在上一節(jié)我們介紹了什么是微服務(wù)并且從概念上理解了微服務(wù)定義，根據(jù) Martin Fowler 的介紹，我們整理出來微服務(wù)的幾個核心點
- a suite of small services：一組小的服務(wù)；
- running in its own process：獨立的進(jìn)程；
- communicating with lightweight：輕量級的通訊；
- built around business capabilities：基于業(yè)務(wù)能力構(gòu)建；
- independently deployable：獨立部署；
- a bare minimum of centralized management：最小的中心化管理。
知其然比知其所以然，微服務(wù)更多是一種風(fēng)格，這一節(jié)起，我們開始進(jìn)行概念落地，向微服務(wù)架構(gòu)邁出第一步。
1. 向微服務(wù)架構(gòu)邁出的第一步
如果已經(jīng)決定要從單體架構(gòu)切換為微服務(wù)架構(gòu)，我們不應(yīng)該糾結(jié)使用什么框架，到底是用 Dubbo 還是 SpringCloud？注冊中心是選擇 ZooKeeper 還是 Eureka ？首先我們最應(yīng)該了解的點是：
- 微服務(wù)能給我們帶來了什么好處，幫我們解決了什么問題；
- 也要了解到微服務(wù)給我們帶來了多少的挑戰(zhàn)，為此我們必須付出什么代價；
- 還要明確的了解到微服務(wù)因為協(xié)同方式不同，為此我們必須更新我們的人員組織架構(gòu)；
在第一節(jié)中，我們提到了一個點，就是微服務(wù)只有在業(yè)務(wù)達(dá)到臨界點的時候采用微服務(wù)才能達(dá)到生產(chǎn)力更優(yōu)，當(dāng)我們的業(yè)務(wù)成長到足夠的復(fù)雜，團(tuán)隊達(dá)到一定得規(guī)模，僅僅依靠好的設(shè)計已經(jīng)不能保證組件之間有清晰的邊界，這個時候?qū)⒔M件之間的邊界強(qiáng)制變成個獨立服務(wù)間的邊界會有很大的幫助。
2. 微服務(wù)與團(tuán)隊之間的關(guān)系
剛開始的互聯(lián)網(wǎng)公司業(yè)務(wù)體量都不大，剛開始一般都會嘗試業(yè)務(wù)模式是否能跑得通，所以一般來說一開始的系統(tǒng)是一個簡單的系統(tǒng)，很可能是一個單體應(yīng)用，團(tuán)隊的規(guī)模也是不大，十來個人就頂天了。
但隨著業(yè)務(wù)的增長，原來只有一個小團(tuán)隊可能就頂不住這么大的工作量了，會分成幾個小團(tuán)隊，甚至?xí)懈鄨F(tuán)隊加入?yún)f(xié)同。例如我們公司，從一開始的開發(fā)小組，就變成了開發(fā) 1 組，開發(fā) 2 組，開發(fā) 3 組。但是我們的系統(tǒng)還是一個單體應(yīng)用，那么它跟分散式團(tuán)隊產(chǎn)生了不匹配的情況，這個時候在團(tuán)隊之間溝通和協(xié)調(diào)成本就變得很高，交付效率降低
幾個團(tuán)隊共同對一個單體應(yīng)用的代碼去開發(fā)和維護(hù)，如果一個團(tuán)隊對這個單體結(jié)構(gòu)進(jìn)行改造引入一些新的功能或新的技術(shù)時，往往需要其他團(tuán)隊的協(xié)作配合，連同做集成測試，運(yùn)維部署才能交付這個應(yīng)用。這時，不僅僅是代碼版本難以維護(hù)，團(tuán)隊之間的溝通協(xié)調(diào)成本變成很高，也往往容易產(chǎn)生摩擦。
為了給解決這個問題提供理論支撐，在微服務(wù)盛行的今天，1967 年的康威講過的一段話也被翻出來，就是出名的康威定律。
康威定律
康威是一個程序員，康威定律是他在 1967 年提出來的，他的原話是這樣：
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)
中文直譯過來大概的意思就是，設(shè)計系統(tǒng)的組織，其產(chǎn)生的設(shè)計等同于組織之內(nèi)、組織之間的溝通結(jié)構(gòu)。
直白一點說，就是我們需要什么樣的系統(tǒng)就要搭配什么樣的團(tuán)隊，當(dāng)我們的系統(tǒng)是根據(jù)業(yè)務(wù)邊界進(jìn)行劃分的話，我們就要按照業(yè)務(wù)的邊界進(jìn)行團(tuán)隊的切分。
上面所描述的問題，其實就是多團(tuán)隊之間和單體應(yīng)用生產(chǎn)不匹配，違反了康威法則。
而微服務(wù)則把單體應(yīng)用拆分成若干獨立的應(yīng)用，把一個大團(tuán)隊拆分為若干獨立的小團(tuán)隊，每個團(tuán)隊負(fù)責(zé)自己的服務(wù)，相互之間不干擾，當(dāng)團(tuán)隊 A 負(fù)責(zé)的服務(wù) A 進(jìn)行開發(fā)修改并不需要其他團(tuán)隊溝通配合，或者說溝通和配置成本變得比較少，一般只發(fā)生在雙方邊界交集的地方，那么這個時候發(fā)現(xiàn)多團(tuán)隊和微服務(wù)之間架構(gòu)的關(guān)系可以映射起來，它符合了康威定律，整體的研發(fā)效率會更加高效。
所以說，單體架構(gòu)轉(zhuǎn)型微服務(wù)架構(gòu)，不僅要考慮技術(shù)的轉(zhuǎn)型，我們的開發(fā)團(tuán)隊也要進(jìn)行轉(zhuǎn)型！！
3. 權(quán)衡利弊
凡是都有利弊，實施微服務(wù)肯定也不是只有好處。架構(gòu)設(shè)計最重要的一點就是權(quán)衡，我們不僅要知道轉(zhuǎn)型微服務(wù)能帶來什么好處，同時也要明確知道微服務(wù)會給我們帶來什么挑戰(zhàn)。下面我們先來看下微服務(wù)給我們帶來的好處有哪些呢？
3.1 利：
清晰的模塊化
我們知道在做軟件設(shè)計，經(jīng)常提到 “高內(nèi)聚，低耦合”，其中模塊化就是非常重要的一點。
正如我們寫代碼一樣，一開始我們寫程序，我們采用類的方式來做模塊，后面開始采用組件或類庫的方式做模塊化，這樣就可以做到工程上的復(fù)用，并且分享給其他人或團(tuán)隊來調(diào)用。
同樣的道理，微服務(wù)在組件的層次上又高了一層，以服務(wù)的方式來做模塊化，每個團(tuán)隊獨立維護(hù)自己的服務(wù)，有明顯的一個邊界，開發(fā)完一個服務(wù)其他團(tuán)隊可以直接調(diào)用這個服務(wù)，不需要像組件通過 jar 包或源碼的方式進(jìn)行分享，所以微服務(wù)的邊界是比較清晰的。
獨立開發(fā)部署
每個團(tuán)隊可以根據(jù)產(chǎn)品經(jīng)理提的需求進(jìn)行開發(fā)測試和部署，一般來說不太需要太過依賴于其他團(tuán)隊進(jìn)行協(xié)作，只有在雙方有邊界交集才需要協(xié)同，而往往在有邊界交集的時候，雙方往往是以接口級的方式進(jìn)行交互，只要每個服務(wù)注重好自己的服務(wù)提供，暴露好提供的服務(wù)即可。
這個對比起單體應(yīng)用，發(fā)布和部署需要很多團(tuán)隊進(jìn)行寫作，而且經(jīng)常只要不慎，單體架構(gòu)里面的業(yè)務(wù)就會相互影響。
在容量和資源的評估上，微服務(wù)的單個服務(wù)更好進(jìn)行評估，大而臃腫的單體摻雜了諸多的業(yè)務(wù)邏輯，使得對資源評估往往不好下手。
技術(shù)多樣性
微服務(wù)是分散式治理，沒有集中治理，每個團(tuán)隊可以根據(jù)團(tuán)隊自己的實際情況和業(yè)務(wù)的實際情況去選擇適合自己的技術(shù)棧，有些團(tuán)隊可能擅長 Java 開發(fā)，有些團(tuán)隊可能更偏向前端，更適合用 nodejs 去開發(fā)服務(wù)，不過這個不是越多越好，技術(shù)棧的引入也是有成本。
3.2 挑戰(zhàn)
(注：我們不說弊，我們說挑戰(zhàn) _ )
分布式帶來的復(fù)雜性
在原來模塊應(yīng)用就是一個應(yīng)用，一個對單體應(yīng)用的架構(gòu)比較熟悉的人可以對整個單體進(jìn)行一個很好的把控。
但在微服務(wù)系統(tǒng)中，可能一下子一個系統(tǒng)就變成了好幾十個服務(wù)，在一些大公司可能是上百個服務(wù)，服務(wù)與服務(wù)之間是通過接口的相互溝通形成了業(yè)務(wù)的實現(xiàn)，那么這個時候整個系統(tǒng)就變得非常復(fù)雜，一般的開發(fā)人員或一個團(tuán)隊都無法理解整個系統(tǒng)是如何工作。
雖說分團(tuán)隊會帶來效率提升，但在整個架構(gòu)層面需要一個對業(yè)務(wù)對系統(tǒng)都非常了解的架構(gòu)師，一旦設(shè)計不合理，交叉調(diào)用，相互依賴頻繁，就會出現(xiàn)牽一發(fā)而動全身的局面。
項目多了，輪子的需求也會變多，各個項目中很容易就出現(xiàn)重復(fù)造輪子的現(xiàn)象，這個時候需要有人專注公共代碼，公共模塊的管控，所以有時候會在各個業(yè)務(wù)開發(fā)組上面又疊加一個小組，叫架構(gòu)組，就是專門干這事。
數(shù)據(jù)最終一致性
由于微服務(wù)本身服務(wù)是分散的，所以背后的數(shù)據(jù)也是分散的，每個團(tuán)隊都有自己的數(shù)據(jù)源，比如團(tuán)隊 A 有訂單數(shù)據(jù)，B 團(tuán)隊也有訂單數(shù)據(jù)，團(tuán)隊 A 修改了訂單數(shù)據(jù)是否應(yīng)該同步給團(tuán)隊 B 的數(shù)據(jù)呢，這里就涉及到數(shù)據(jù)一致性問題。
還有就是我們會發(fā)現(xiàn)傳統(tǒng)的 ACID 事務(wù)在微服務(wù)失效，在本地事務(wù)中，是由資源管理日（RM）直接提供事務(wù)支持，數(shù)據(jù)一致性在本地事務(wù)保證。但在分布式中，分布式事務(wù)比較流行的是兩階段提交（2PC），但兩階段提交也不能完全保證數(shù)據(jù)一致性問題，并且還存在同步阻塞的問題，所以提出最終一致性的說法，包含了 CAP 和 Bese 理論。
運(yùn)維的復(fù)雜性
在以前的運(yùn)維只需要管理的是機(jī)器 + 單體應(yīng)用，而在分布式系統(tǒng)中存在大量的服務(wù)，服務(wù)與服務(wù)之間是相互協(xié)同和依賴，那么對分布式系統(tǒng)的資源，容量規(guī)劃，對監(jiān)控，對整個系統(tǒng)的可靠性和穩(wěn)定性都非常具備挑戰(zhàn)的。
測試的復(fù)雜性
對于測試人員來說，在單體應(yīng)用上，一個測試團(tuán)隊只需要測試好一個單體應(yīng)用就可以，到了分布式系統(tǒng)，各個服務(wù)是分布在各個團(tuán)隊上，這個對測試團(tuán)隊來說要求就很高，在做功能集成測試時是需要調(diào)動很多的團(tuán)隊配合去聯(lián)合做集成測試。
治理的復(fù)雜性
上面說了，單體應(yīng)用轉(zhuǎn)型微服務(wù)決對不是考慮使用哪套微服務(wù)框架就了事了，更多的復(fù)雜性集中在治理的環(huán)節(jié)，一個公司人多了就需要一個行政部門，對公司員工進(jìn)行服務(wù)（管理），一個微服務(wù)系統(tǒng)多了也是需要進(jìn)行管理和治理。
之前說微服務(wù)拆分后，每個內(nèi)部的團(tuán)隊可以使用豐富差異化的技術(shù)棧，但是，在協(xié)同各個服務(wù)之間環(huán)節(jié)是需要統(tǒng)一或者說標(biāo)準(zhǔn)化管理，例如，服務(wù)注冊發(fā)現(xiàn)；服務(wù)的負(fù)載均衡，監(jiān)控 - 日志；監(jiān)控 - metrics; 監(jiān)控 - 全鏈路跟蹤；限流熔斷；安全 - 訪問控制；序列化；網(wǎng)絡(luò)傳輸；代碼管理；統(tǒng)一異常處理；文檔；集中配置中心，后臺集成 MQ,Cache；
你會發(fā)現(xiàn)我們整個專欄有一半的篇幅是圍繞著這些治理復(fù)雜性去進(jìn)行展開，這個在后續(xù)會慢慢的講到，甚至可以這么說，整個微服務(wù)的構(gòu)建，運(yùn)維都是跟這些復(fù)雜性在進(jìn)行搏斗，只有根據(jù)自己業(yè)務(wù)的情況克服這些復(fù)雜的因素，才能可靠的高效推進(jìn)業(yè)務(wù)的進(jìn)展。
4. 總結(jié)
本小節(jié)我們對微服務(wù)的利和弊進(jìn)行了分析和整理，但實際情況可能遠(yuǎn)遠(yuǎn)比概念復(fù)雜，對于不同的業(yè)務(wù)不同的系統(tǒng)，往往成本和收益是具有不同的權(quán)重。
最終我們得回到業(yè)務(wù)和現(xiàn)實層面進(jìn)行利弊的權(quán)衡
- 我們的技術(shù)是否有所儲備 ？
- 我們是否要構(gòu)建一個較大的平臺 ？
- 我們的團(tuán)隊是否需要擴(kuò)展 ？
好了，幾點思考。下一節(jié)我們將開始對微服務(wù)的服務(wù)和技術(shù)架構(gòu)進(jìn)行分層。