在業務網際網路化之前，我們建設的大部分it系統都是供內部員工使用的，主要用於提公升辦公、管理的規範和效率，以及通過無紙化來降低辦公成本等。但現在網際網路已經成為獲客、銷售和服務的載體，跟以往相比，業務形態的變化越來越快，也越來越多樣化。原先我們經年累月在物理世界構築起的防禦城牆，例如：廣告渠道（廣播電視或戶外等）、銷售網路（**人或實體店等）、客服中心等，都被網際網路瞬間推平了，這完全是降維打擊。
行業邊界變得越來越模糊，跨界競爭越來越白熱化，在這個沒有天然屏障的世界裡贏者真的可以通吃。在這個巨變不斷的時代，再睿智的管理者也無法預見業務的發展，要不然各行各業不會出現這麼多新巨頭。就像在兩眼抹黑的環境下，我們只能小步前行，不斷創新、迭代和試錯。天下武功唯快不破，內在的夢想和外在的壓力，呼喚更加精細的分工、更加廣密的合作，只有這樣才能提公升進化的速度，從而更好地適應不斷變化的外部環境。
為什麼說微服務可以加速分工呢？單體式架構的特點就是不同型別的業務邏輯混雜在一起，彼此之間沒有明顯的物理邊界，所有人都在維護同乙個**庫，耦合度非常高。在業務需要快速迭代的當下，每次發版本都要全量回歸測試，無法並行開發，這樣很難提公升速度。微服務化就是借助領域驅動設計（ddd）理論將單體式拆解成多個彼此獨立的業務元件，高內聚低耦合，每個元件聚焦各自業務，避免變更範圍無法有效控制。
除此之外，著名的「康威理論」告訴我們：組織架構決定了系統架構，每個微服務元件都應該由乙個小而精的團隊維護，最適合的團隊規模就是「兩張披薩」可以吃飽的人數。通過限制**和人員的規模，微服務讓業務更聚焦、分工更精細、組織更簡單、溝通更高效。
沒有分工就沒有合作，如果每個人的才能相似，又幹同樣的活，那合作的必要性就降低了，更多是競爭。為什麼微服務可以促進合作呢？我們可以將合作的雙方抽象成兩個節點，合作就是在兩個節點之間建立連線。在單體式時代，系統間的互動存在許多協議，例如：ejb t3、rmi、soap、dubbo、hessian 等，跟不同的系統通訊需要依賴不同的協議，這種情況下學習、溝通和維護成本都很高，不利於合作。而微服務將通訊協議統一為http，元件或系統間的互動全部採用restful api，報文以json為編碼格式，同時引進服務註冊、發現等機制。這些技術理念都是借鑑自世界上最大的合作網路：網際網路，包括超文字傳輸協議http、網域名稱系統dns。簡單、統一和松耦合的機制有利於合作。
因此，微服務可以幫我們加速分工、促進合作。在微服務架構下，軟體的復用率更高，研發的並行性也更高，從而以更快的迭代速度打磨出更好的產品，在更高的質量屬性保障下全天候服務全網使用者，同時資源利用更精細高效，讓我們的產品具備更好的成本優勢。撥開雲霧，看清微服務的本質，找到我們學習新技術的內驅力。
當然，微服務想要發揮最佳的效果，必須要跟容器雲和devops結合，應用所依賴的其他服務最好是雲化的，例如：傳統的網路儲存方案nas就需要改為雲儲存，這樣應用和關聯服務都具備彈性伸縮能力，在業務量爆發性增長的情況下，系統能夠快速地擴容，無需從頭到尾手工擴容。記住一句話：微服務，就是加速分工、促進合作，讓我們進化得更快！
堅持原創不易，如果你覺得有價值，麻煩動動手指點下文 「推薦
關注「it老兵哥」，賦能程式人生
近期熱評文章：架構師入門系列
為什麼使用微服務
1.單機服務 此時我們就多加了幾台web伺服器，從單機變成了乙個集群，甚至我們可以寫乙個指令碼，當web伺服器壓力過大時動態增加web伺服器。這下web伺服器的壓力不大了，我們就這樣安穩的過上了幾個月。然而有一天伺服器又出問題了 先是mysql伺服器cpu標高，然後是web伺服器宕機。此時我們會發現...
為什麼要微服務（服務化）？
微服務架構 的話題非常之火，很多朋友都在小窗我，說怎麼做服務化？解答 怎麼做 之前，先得了解 為什麼做 畫外音 做技術千萬不能是這種思路，別人都在做，所以我們也要搞 並不是所有的業務都適合 服務化 網際網路高可用架構，到底為什麼要服務化？服務化之前，高可用架構是什麼樣的？在服務化之前，網際網路的典型...
為什麼要微服務架構服務化？
微服務架構，這 5 年左右一直被認可，是軟體架構的未來方向。需要大家理解的是，為什麼需要服務化。比如微服務架構對企業來說，帶來什麼價值？有啥弊端？這裡 一下微服務架構，主要還是在理解 why 為什麼需要服務化？微服務架構，主要是多了個 微 亞馬遜有個粗粗的定義 乙個微服務應用工程的所有開發 測試 運...