本文首發自「慕課網」，想了解更多IT幹貨内容，程式員圈内熱聞，歡迎關注！
作者| 慕課網精英講師陳于吉吉
1. 向微服務架構邁出的第一步
如果已經決定要從單體架構切換為微服務架構，我們不應該糾結使用什麼架構，到底是用 Dubbo 還是 SpringCloud？注冊中心是選擇 ZooKeeper 還是 Eureka ？首先我們最應該了解的點是：
- 微服務能給我們帶來了什麼好處，幫我們解決了什麼問題；
- 也要了解到微服務給我們帶來了多少的挑戰，為此我們必須付出什麼代價；
- 還要明确的了解到微服務因為協同方式不同，為此我們必須更新我們的人員組織架構；
微服務隻有在業務達到臨界點的時候采用微服務才能達到生産力更優，當我們的業務成長到足夠的複雜，團隊達到一定得規模，僅僅依靠好的設計已經不能保證元件之間有清晰的邊界，這個時候将元件之間的邊界強制變成個獨立服務間的邊界會有很大的幫助。
2. 微服務與團隊之間的關系
剛開始的網際網路公司業務體量都不大，剛開始一般都會嘗試業務模式是否能跑得通，是以一般來說一開始的系統是一個簡單的系統，很可能是一個單體應用，團隊的規模也是不大，十來個人就頂天了。
但随着業務的增長，原來隻有一個小團隊可能就頂不住這麼大的工作量了，會分成幾個小團隊，甚至會有更多團隊加入協同。例如我們公司，從一開始的開發小組，就變成了開發 1 組，開發 2 組，開發 3 組。但是我們的系統還是一個單體應用，那麼它跟分散式團隊産生了不比對的情況，這個時候在團隊之間溝通和協調成本就變得很高，傳遞效率降低
幾個團隊共同對一個單體應用的代碼去開發和維護，如果一個團隊對這個單體結構進行改造引入一些新的功能或新的技術時，往往需要其他團隊的協作配合，連同做內建測試，運維部署才能傳遞這個應用。這時，不僅僅是代碼版本難以維護，團隊之間的溝通協調成本變成很高，也往往容易産生摩擦。
為了給解決這個問題提供理論支撐，在微服務盛行的今天，1967 年的康威講過的一段話也被翻出來，就是出名的康威定律。
康威定律
康威是一個程式員，康威定律是他在 1967 年提出來的，他的原話是這樣：
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)
中文直譯過來大概的意思就是，設計系統的組織，其産生的設計等同于組織之内、組織之間的溝通結構。
直白一點說，就是我們需要什麼樣的系統就要搭配什麼樣的團隊，當我們的系統是根據業務邊界進行劃分的話，我們就要按照業務的邊界進行團隊的切分。
上面所描述的問題，其實就是多團隊之間和單體應用生産不比對，違反了康威法則。
而微服務則把單體應用拆分成若幹獨立的應用，把一個大團隊拆分為若幹獨立的小團隊，每個團隊負責自己的服務，互相之間不幹擾，當團隊 A 負責的服務 A 進行開發修改并不需要其他團隊溝通配合，或者說溝通和配置成本變得比較少，一般隻發生在雙方邊界交集的地方，那麼這個時候發現多團隊和微服務之間架構的關系可以映射起來，它符合了康威定律，整體的研發效率會更加高效。
是以說，單體架構轉型微服務架構，不僅要考慮技術的轉型，我們的開發團隊也要進行轉型！！
3. 權衡利弊
凡是都有利弊，實施微服務肯定也不是隻有好處。架構設計最重要的一點就是權衡，我們不僅要知道轉型微服務能帶來什麼好處，同時也要明确知道微服務會給我們帶來什麼挑戰。下面我們先來看下微服務給我們帶來的好處有哪些呢？
3.1 利：
清晰的子產品化
我們知道在做軟體設計，經常提到 “高内聚，低耦合”，其中子產品化就是非常重要的一點。
正如我們寫代碼一樣，一開始我們寫程式，我們采用類的方式來做子產品，後面開始采用元件或類庫的方式做子產品化，這樣就可以做到工程上的複用，并且分享給其他人或團隊來調用。
同樣的道理，微服務在元件的層次上又高了一層，以服務的方式來做子產品化，每個團隊獨立維護自己的服務，有明顯的一個邊界，開發完一個服務其他團隊可以直接調用這個服務，不需要像元件通過 jar 包或源碼的方式進行分享，是以微服務的邊界是比較清晰的。
獨立開發部署
每個團隊可以根據産品經理提的需求進行開發測試和部署，一般來說不太需要太過依賴于其他團隊進行協作，隻有在雙方有邊界交集才需要協同，而往往在有邊界交集的時候，雙方往往是以接口級的方式進行互動，隻要每個服務注重好自己的服務提供，暴露好提供的服務即可。
這個對比起單體應用，釋出和部署需要很多團隊進行寫作，而且經常隻要不慎，單體架構裡面的業務就會互相影響。
在容量和資源的評估上，微服務的單個服務更好進行評估，大而臃腫的單體摻雜了諸多的業務邏輯，使得對資源評估往往不好下手。
技術多樣性
微服務是分散式治理，沒有集中治理，每個團隊可以根據團隊自己的實際情況和業務的實際情況去選擇适合自己的技術棧，有些團隊可能擅長 Java 開發，有些團隊可能更偏向前端，更适合用 nodejs 去開發服務，不過這個不是越多越好，技術棧的引入也是有成本。
3.2 挑戰
(注：我們不說弊，我們說挑戰 _ )
分布式帶來的複雜性
在原來子產品應用就是一個應用，一個對單體應用的架構比較熟悉的人可以對整個單體進行一個很好的把控。
但在微服務系統中，可能一下子一個系統就變成了好幾十個服務，在一些大公司可能是上百個服務，服務與服務之間是通過接口的互相溝通形成了業務的實作，那麼這個時候整個系統就變得非常複雜，一般的開發人員或一個團隊都無法了解整個系統是如何工作。
雖說分團隊會帶來效率提升，但在整個架構層面需要一個對業務對系統都非常了解的架構師，一旦設計不合理，交叉調用，互相依賴頻繁，就會出現牽一發而動全身的局面。
項目多了，輪子的需求也會變多，各個項目中很容易就出現重複造輪子的現象，這個時候需要有人專注公共代碼，公共子產品的管控，是以有時候會在各個業務開發組上面又疊加一個小組，叫架構組，就是專門幹這事。
資料最終一緻性
由于微服務本身服務是分散的，是以背後的資料也是分散的，每個團隊都有自己的資料源，比如團隊 A 有訂單資料，B 團隊也有訂單資料，團隊 A 修改了訂單資料是否應該同步給團隊 B 的資料呢，這裡就涉及到資料一緻性問題。
還有就是我們會發現傳統的 ACID 事務在微服務失效，在本地事務中，是由資源管理日（RM）直接提供事務支援，資料一緻性在本地事務保證。但在分布式中，分布式事務比較流行的是兩階段送出（2PC），但兩階段送出也不能完全保證資料一緻性問題，并且還存在同步阻塞的問題，是以提出最終一緻性的說法，包含了 CAP 和 Bese 理論。
運維的複雜性
在以前的運維隻需要管理的是機器 + 單體應用，而在分布式系統中存在大量的服務，服務與服務之間是互相協同和依賴，那麼對分布式系統的資源，容量規劃，對監控，對整個系統的可靠性和穩定性都非常具備挑戰的。
測試的複雜性
對于測試人員來說，在單體應用上，一個測試團隊隻需要測試好一個單體應用就可以，到了分布式系統，各個服務是分布在各個團隊上，這個對測試團隊來說要求就很高，在做功能內建測試時是需要調動很多的團隊配合去聯合做內建測試。
治理的複雜性
上面說了，單體應用轉型微服務決對不是考慮使用哪套微服務架構就了事了，更多的複雜性集中在治理的環節，一個公司人多了就需要一個行政部門，對公司員工進行服務（管理），一個微服務系統多了也是需要進行管理和治理。
之前說微服務拆分後，每個内部的團隊可以使用豐富差異化的技術棧，但是，在協同各個服務之間環節是需要統一或者說标準化管理，例如，服務注冊發現；服務的負載均衡，監控 - 日志；監控 - metrics; 監控 - 全鍊路跟蹤；限流熔斷；安全 - 通路控制；序列化；網絡傳輸；代碼管理；統一異常處理；文檔；集中配置中心，背景內建 MQ,Cache；
可以這麼說，整個微服務的建構，運維都是跟這些複雜性在進行搏鬥，隻有根據自己業務的情況克服這些複雜的因素，才能可靠的高效推進業務的進展。
4. 總結
本篇文章我們對微服務的利和弊進行了分析和整理，但實際情況可能遠遠比概念複雜，對于不同的業務不同的系統，往往成本和收益是具有不同的權重。
歡迎關注「慕課網」，發現更多IT圈優質内容，分享幹貨知識，幫助你成為更好的程式員！