微服務架構是團隊面對互聯網產品爆發式增長的最優選擇，要解決的是快速迭代、高可靠和高可用等問題，把復雜度很高的產品拆分成一些較小的模塊，并遵循康威定律，每一個模塊用5-9個小團隊來維護，這樣可以減少溝通成本，提高協作效率，更好地實現快速迭代和彈性擴展。
采用微服務架構改造，引入各種復雜性，如部署工作量的增加、復雜鏈路的監控難題，這就是為微服務而微服務，只會得不償失。在實施的過程中不能簡單的使用某些個微服務框架或者組件一蹴而就，而是需要將業務、技術和運維有機結合起來，配合同步實施，并且在此過程中還需要趟過很多的坑才能夠取得成功。
復雜業務拆分可能無法一步到位，因為復雜，每個業務并不一定只能拆成一個組件，龐大的業務拆分出相對獨立和龐大的業務，但如果業務較小而又比較多，且類型相似也可以不用著急拆分。
舉網易考拉的例子，工程數量由最初的 7 到后來的 150+ 再到目前的 400+，都是根據實際情況決定的。中間的狀態，可能不是嚴格意義上的微服務架構，但屬于分布式服務架構——不過這不是那么重要，重要的是符合業務發展階段的需求。醫院的急診，既看發熱又看胃痛，固然分工沒那么精細，但我們也不能說就是錯的。
分布式是什么？
對于分布式架構，我們根據設計期的架構思想和運行期的不同結構分為：面向服務架構、分布式服務架構、微服務架構。
1.面向服務架構︰以業務服務的角度和服務總線的方式(一般是WebService與ESB）考慮系統架構和企業IT治理;
2.分布式服務架構：基于去中心化的分布式服務框架與技術，考慮系統架構和服務治理;
3.微服務架構∶微服務架構可以看做是面向服務架構和分布式服務架構的拓展，使用更細粒度的服務和一組設計準則來考慮大規模的復雜系統架構設計。
統的企業集成領域的EAI架構模式，本身還是各個系統獨立部署，但是各系統之間的部分業務使用特定的技術打通了，因此我們可以看做是單體和分布式之間的過渡狀態。
分布式服務架構與微服務架構概念的區別與聯系
分布式：分散壓力。
微服務：分散能力。
?
分布式：不同模塊部署在不同服務器上;
作用：分布式解決網站高并發帶來問題;
集群：相同的服務;
多臺服務器部署相同應用構成一個集群;
作用：通過負載均衡設備共同對外提供服務;
SOA［組裝服務/ESB企業服務總線］;
業務系統分解為多個組件，讓每個組件都獨立提供離散，自治，可復用的服務能力;
通過服務的組合和編排來實現上層的業務流程;
作用：簡化維護，降低整體風險，伸縮靈活;
微服務［找到服務/微服務網關open API］;
架構設計概念，各服務間隔離（分布式也是隔離），自治（分布式依賴整體組合）其它特性（單一職責，邊界，異步通信，獨立部署）是分布式概念的跟嚴格執行;
SOA到微服務架構的演進過程;
作用：各服務可獨立應用，組合服務也可系統應用。
