微服務，爲何能夠加速分工、促進合做？

知其然，知其因此然。在上一篇博文中咱們聊到 微服務的本質 就是一種新的協做機制，能夠加速分工、促進合做，但爲何微服務有這種效用呢？今天咱們來聊聊其背後的緣由。

在業務互聯網化以前，咱們建設的大部分IT系統都是供內部員工使用的，主要用於提高辦公、管理的規範和效率，以及經過無紙化來下降辦公成本等。但如今互聯網已經成爲獲客、銷售和服務的載體，跟以往相比，業務形態的變化愈來愈快，也愈來愈多樣化。原先咱們經年累月在物理世界構築起的防護城牆，例如：廣告渠道（廣播電視或戶外等）、銷售網絡（代理人或實體店等）、客服中心等，都被互聯網瞬間推平了，這徹底是降維打擊。

行業邊界變得愈來愈模糊，跨界競爭愈來愈白熱化，在這個沒有自然屏障的世界裏贏者真的能夠通吃。在這個鉅變不斷的時代，再睿智的管理者也沒法預見業務的發展，要否則各行各業不會出現這麼多新巨頭。就像在兩眼抹黑的環境下，咱們只能小步前行，不斷創新、迭代和試錯。天下武功惟快不破，內在的夢想和外在的壓力，呼喚更加精細的分工、更加廣密的合做，只有這樣才能提高進化的速度，從而更好地適應不斷變化的外部環境。

領域驅動設計讓分工更加高效

爲何說微服務能夠加速分工呢？單體式架構的特色就是不一樣類型的業務邏輯混雜在一塊兒，彼此之間沒有明顯的物理邊界，全部人都在維護同一個代碼庫，耦合度很是高。在業務須要快速迭代的當下，每次發版本都要全量回歸測試，沒法並行開發，這樣很難提高速度。微服務化就是藉助領域驅動設計（DDD）理論將單體式拆解成多個彼此獨立的業務組件，高內聚低耦合，每一個組件聚焦各自業務，避免變動範圍沒法有效控制。

除此以外，著名的「康威理論」告訴咱們：組織架構決定了系統架構，每一個微服務組件都應該由一個小而精的團隊維護，最適合的團隊規模就是「兩張披薩」能夠吃飽的人數。經過限制代碼和人員的規模，微服務讓業務更聚焦、分工更精細、組織更簡單、溝通更高效。

交互機制標準化讓合做更簡單

沒有分工就沒有合做，若是每一個人的才能類似，又幹一樣的活，那合做的必要性就下降了，更可能是競爭。爲何微服務能夠促進合做呢？咱們能夠將合做的雙方抽象成兩個節點，合做就是在兩個節點之間創建連線。在單體式時代，系統間的交互存在許多協議，例如：EJB T三、RMI、SOAP、Dubbo、Hessian 等，跟不一樣的系統通信須要依賴不一樣的協議，這種狀況下學習、溝通和維護成本都很高，不利於合做。而微服務將通信協議統一爲HTTP，組件或系統間的交互所有采用RESTful API，報文以JSON爲編碼格式，同時引進服務註冊、發現等機制。這些技術理念都是借鑑自世界上最大的合做網絡：互聯網，包括超文本傳輸協議HTTP、域名系統DNS。簡單、統一和鬆耦合的機制有利於合做。

所以，微服務能夠幫咱們加速分工、促進合做。在微服務架構下，軟件的複用率更高，研發的並行性也更高，從而以更快的迭代速度打磨出更好的產品，在更高的質量屬性保障下全天候服務全網用戶，同時資源利用更精細高效，讓咱們的產品具有更好的成本優點。撥開雲霧，看清微服務的本質，找到咱們學習新技術的內驅力。固然，微服務想要發揮最佳的效果，必需要跟容器雲和DevOps結合，應用所依賴的其餘服務最好是雲化的，例如：傳統的網絡存儲方案NAS就須要改成雲存儲，這樣應用和關聯服務都具有彈性伸縮能力，在業務量爆發性增加的狀況下，系統可以快速地擴容，無需從頭至尾手工擴容。記住一句話：微服務，就是加速分工、促進合做，讓咱們進化得更快！

堅持原創不易，若是你以爲有價值，麻煩動動手指點個 「 贊 」，讓更多小夥伴能夠看到，我會更有動力堅持分享的。另外，我後續還會分享職業規劃、應聘面試、技能提高、影響力打造等經驗，歡迎 關注 本專欄或微信公衆號 「 IT老兵哥 」！

關注「IT老兵哥」，賦能程序人生！近期熱評文章《 架構師入門系列 》：

1. 架構究竟是什麼，你知道嗎？
2. 架構都有哪些，我該怎麼選？
3. 架構師都幹什麼，你知道嗎？
4. 練就哪些技能才勝任架構師？
5. 怎樣才能搞定上下游的客戶？
6. 如何從開發崗轉型作架構師？
7. 程序員爲何必需要懂架構？