這些年互聯網的快速發展，分布式，微服務的概念風靡整個行業。在企業中IT的架構，從過去的單體應用架構發展到現在廣為人知的微服務架構。不說別的，現在出去面試都不好意思說自己不知道微服務。微服務是一種架構風格，將我們的業務拆分若干個服務，為我們的開發帶來了極大的便利。過去，架構是從單體應用架構-->分布式架構-->微服務發展。

單體應用架構

這種架構在老的JAVA web項目中還存在，就是一套代碼擼到底。就是項目中從controller到service再到dao層，不進行任何的拆分，所有的代碼都堆積在一個項目中。這樣打出來的war巨大無比，啟動都要費好多時間。比如下面的例子：

這樣就把供應鏈所有的的功能業務代碼放在項目中，可想而知，代碼量有多大。不過這種架構方式既有缺點又有優點優點：

簡單方便，易于開發。所有人員都在一個項目上做開發，沒有接口的遠程調用，很方便。
相對容易測試以及部署運維。打包成測試包之后，部署到測試環境即可從頭到尾進行測試。而且不受網絡影響
缺點：
代碼不易管理。沒有進行拆分，也就是所有的開發人員都在一個項目上提交代碼，就會出現我們非常惡心的代碼沖突~
代碼耦合度高。可能僅僅修改一小個代碼，就會導致整個系統出現問題，不敢下手隨意修改代碼啊，淚奔~
系統擴展性差。要增加或者上線某個小功能的時候，整個應用都得停下來部署，用戶體驗太差了~
系統啟動慢。毫無疑問，模塊太多了也是一種累贅。
因此這種架構慢慢被淘汰，衍生出分布式架構

分布式應用架構

分布式架構從業務的不同進行拆分，將我們的單體應用拆分多個業務服務系統，每個服務系統就是一個單體應用，他們之間通過商定好的api進行調用。例如將上面的例子拆分，將龐大的供應鏈系統拆分成采供管理系統，資產管理系統，倉儲管理系統：

這種拆分，大大降低了代碼的耦合度，提高了服務的可用性。從原來一個大項目重新分配任務小組，每個小組負責自己的業務項目，業務服務之間通過api調用，每個服務模塊運行在不同的主機上。當然這種分布式架構一下子表現出的優點也表現出缺點。優點：

降低了業務模塊之間耦合度。將模塊拆分之后，通過接口進行調用，其他業務代碼不受影響。
項目細分化，不同的項目組負責不同的任務。
系統擴展性高，靈活。增加或者改造某個功能時，不需要牽一發而動全身影響到別的模塊。不會存在因為其他服務不存在而造成我自己的服務不能啟動或者不可用的問題。
缺點：
受網絡影響。系統之間經過api遠程調用，不僅增加了接口開發工作量，而且受網絡限制。
數據的一致性問題。
增加了運維工作量。
這種分布式架構按照角色來劃分，分為：生產者（服務提供方），消費者（服務調用方）。
應用場景：項目中使用kafka就是一個分布式系統。

微服務應用架構

其實90%的微服務架構就是分布式架構一種延申。微服務的概念最早源于Martin Fowler發表的一篇《Microsevices》。這種微服務按照業務的功能繼續拆分成相互獨立的微服務，各個微服務之間是松耦合的，也是通過遠程協議進行調用。例如我們將采供管理再一次拆分，將采供管理系統拆分成需求管理，采購管理，入庫管理：

這種拆分方式將分布式應用架構更加細分化。各個微服務之間通過各種遠程協議進行同步/異步調用，各個微服務之間也是獨立部署。當然這種服務架構也同樣。除了具備分布式架構的缺點外，還有：

通信，http請求速度慢，通常一個操作可能會涉及到多個微服務的相互調用，如果為了完成一個操作而多次從服務端調用不同的微服務，http請求的耗時可能會成為瓶頸。
增加復雜性以及加大了技術支持。在微服務中不僅僅服務之間的調用這么簡單，還需要許多技術支撐，比如服務注冊中心，熔斷器，鏈路跟中，分布式配置中心，分布式事務等等技術上的支持，加大了開發人員的額外任務量。
服務眾多，其測試，部署，監控變得更加復雜。
下面這張是從網上拷貝下來的微服務架構圖，可以看出來需要好多技術來支持構成完整的微服務架構：

當然這種帶來的弊端遠遠小于帶來的好處。

微服務技術方案的選型

市面上支持微服務的技術棧是多種多樣的，但是按照現在比較流行的，無非就是springcloud以及dubbo方案。springcloud是spring社區下的項目，提供了完整的落地方案，包括服務發現，網關，配置中心，鏈路跟蹤等。而dubbo是阿里巴巴基于java分布式服務治理框架，但是它沒有提供完整的解決方案，而是專注于RPC領域。兩者技術選型對比：