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