對兩者的東西進行區分以及比較，有時候是源于兩者有許多的共同之處。兩者概念上不同，可解決的問題的復雜程度不一樣。但是區分兩者的不同之處是更有易于實現微服務架構和分布式架構的最大價值。用戶選擇使用何種架構的時候，得需要根據自己的實際情況進行選擇。

從概念理解，分布式服務架構強調的是服務化以及服務的分散化，微服務則更強調服務的專業化和精細分工;從實踐的角度來看，微服務架構通常是分布式服務架構，反之則未必成立。所以，選擇微服務通常意味著需要解決分布式架構的各種難題。

微服務架構是團隊面對互聯網產品爆發式增長的最優選擇，要解決的是快速迭代、高可靠和高可用等問題，把復雜度很高的產品拆分成一些較小的模塊，并遵循康威定律，每一個模塊用5-9個小團隊來維護，這樣可以減少溝通成本，提高協作效率，更好地實現快速迭代和彈性擴展。比如網易考拉，先用網易內部的私有云以及容器服務、負載均衡等解決并發流量的問題，再借助網易云輕舟微服務，拆分了 400 多個工程(模塊)，進一步提升迭代速度和擴展能力，通過服務治理、系統運維自動化等，可以提升可靠性和可用性。這是先有分布化后有服務化的例子。

網易考拉微服務改造及效果

既沒有規模又不需要太多變化的業務，如果采用微服務架構改造，引入各種復雜性，比如部署工作量的增加、復雜鏈路的監控難題，這就是為微服務而微服務，只會得不償失。

當然，復雜業務拆分可能無法一步到位，因為復雜，每個業務并不一定只能拆成一個組件，龐大的業務拆分出相對獨立和龐大的業務，但如果業務較小而又比較多，且類型相似，也可以不用著急拆分。再舉網易考拉的例子，工程數量由最初的 7 到后來的 150+ 再到目前的 400+，都是根據實際情況決定的。中間的狀態，可能不是嚴格意義上的微服務架構，但屬于分布式服務架構——不過這不是那么重要，重要的是符合業務發展階段的需求。醫院的急診，既看發熱又看胃痛，固然分工沒那么精細，但我們也不能說就是錯的。

這是對微服務架構和分布式架構的區別與聯系簡要地介紹，不過都是為對象是服務的，但通過一些對象的使用的情況來看的話，它于不同的服務對象所帶來的效果是不一樣的。因為它們需要考慮兩者的數量以及服務對象以及業務的需求。想要了解更多關于軟件研發的信息，請繼續關注中培偉業。