隨着互聯⽹的發展，⽤戶群體逐漸擴⼤，⽹站的流量成倍增⻓，常規的單體架構已⽆法滿⾜請求壓⼒和業務的快速迭代，架構的變化勢在必⾏。下面咱們就一起來看看互聯網架構的由單體架構到微服務架構的演變過程。
一、單體架構
在剛開始的時候，企業的⽤戶量、數據量規模都⽐較⼩，項⽬所有的功能模塊都放在⼀個⼯程中編碼、編譯、打包並且部署在⼀個Tomcat容器中的架構模式就是單體應⽤架構，這樣的架構既簡單實 ⽤、便於維護，成本⼜低，成為了那個時代的主流架構⽅式。這時候由於業務以及規模都比較小，所以無論服務以及DB都是使用單節點（all-in-one）的方式進行部署，這就是單體架構。下面我們來看一下這種架構下的優缺點
優點：
1、項⽬前期開發節奏快，團隊成員少的時候能夠快速迭代
2、架構簡單：MVC架構，只需要借助IDE開發、調試即可
3、易於測試：只需要通過單元測試或者瀏覽器完成
4、易於部署：打包成單⼀可執⾏的jar或者打成war包放到容器內啟動
缺點：
1、隨着時間推移業務增加，功能不斷迭代，項目會不斷變得臃腫，業務耦合嚴重，隨着項目團隊增大，溝通成本高，項目啟動慢
2、新增業務困難：在已經亂如麻的系統中增加新業務，維護舊功能，⼀腳踩進去全是不可預測 的問題。新⼈來了以后很難接⼿任務，學習成本⾼
3、核⼼業務與邊緣業務混合在⼀塊，出現問題互相影響
在這種架構下，就像我們在平時做開發的時候對類、方法等就沒有什么設計，所有功能都往一個類中塞一個功能一個方法搞定，就會給人一種外面的人不想進去，里面的人想趕緊出來的感覺，而且除了問題排查巨困難。
隨着業務量的不斷增加，我們的單體（單節點部署）就會滿足不了需求，這時候架構上也會對應做一些調整。比如：應用集群部署、負載均衡、緩存、讀寫分離等，這樣能減少不少服務壓力，也就是分流，既然一個服務器干不了，我們就多來幾台服務器，一台做一部分事情。
二、垂直應⽤架構
為了避免單體架構上出現的那些問題，大家開始對應用按照業務做垂直划分，把原來的的一個單體架構拆成一堆單體應用，這時候就由原來的單應用變成了多應用部署，這就是垂直架構。下面我們也來看看做垂直划分之后的架構的優缺點
優點：
1、系統拆分實現了流量分擔，解決了並發問題
2、可以針對不同模塊進⾏優化
3、⽅便⽔平擴展，負載均衡，容錯率提⾼
4、系統間相互獨⽴，互不影響，新的業務迭代時更加⾼效
缺點：
1、服務之間相互調⽤，如果某個服務的端⼝或者ip地址發⽣改變，調⽤的系統得⼿動改變（也就是硬編碼）
2、搭建集群之后，實現負載均衡⽐較復雜，如：內⽹負載，在遷移機器時會影響調⽤⽅的路 由，導致線上故障
3、服務之間調⽤⽅式不統⼀，基於 httpclient 、 webservice ，接⼝協議不統⼀
4、服務監控不到位：除了依靠端⼝、進程的監控，調⽤的成功率、失敗率、總耗時等等這些監 控指標是沒有的
這時候其實就開始出現了一種思想：分治。也就是分開來治理，為什么單體架構能存在那么些問題？歸根結底還是在單體架構下一個應用要做的事情太多，所以的事情都交給一個服務來做，服務太忙了也太亂了。垂直架構下會把單體架構按照業務拆成多個應用進行部署，每個應用負責一部分業務功能。這樣就能把壓力都分開一點，每個應用承受一些。這就有點想我們設計模式中的組合模式了，一人干一點，誰也不太累。
三、SOA架構
SOA (Service-Oriented Architecture)，即⾯向服務的架構。其思想就是根據實際業務，把系統拆分成合適的、獨⽴部署的模塊，模塊之間相互獨⽴（通過Webservice/Dubbo等技術進⾏通信）。可以理解為拆分出來的每個系統都是一個個的組件，組件與組件之間都是通過服務進行調用。下面我們一起來看看SOA架構下的優缺點
優點：
1、分布式
2、松耦合
3、擴展靈活
4、可重⽤
缺點：
1、服務抽取粒度較⼤
2、服務調⽤⽅和提供⽅耦合度較⾼（接⼝耦合度）
在做了垂直划分以后，模塊隨之增多，維護的成本在也變⾼，⼀些通⽤的業務和模塊重復的越來越多，為了解決垂直應用上出現的那些問題如：接⼝協議不統⼀、服務⽆法監控、服務的負載均衡等阿里巴巴搞了一個高效的JavaRpc框架（僅僅是soa架構框架的一個代表）
Dubbo，它提供了三⼤核⼼能⼒：⾯向接⼝的遠程⽅法調⽤，智能容錯和負載均衡，以及服務⾃動注冊和發現。
四、微服務架構
在SOA架構下雖然能解決大部分的問題，但是由於他自身的缺點，依然不那么盡如人意，其實主要還是在SOA架構下拆分粒度不是很細，因此大家又在SOA架構下進行了拓展，將服務粒度拆分得更細這就引出了微服務架構。這種架構模式下它拆分粒度更⼩、服務更獨⽴。把應⽤拆分成為⼀個個微⼩的服務，不同的服務可以使⽤不同的開發語⾔和存儲，服務之間往往通過Restful等輕量級通信。微服務架構關鍵在於微⼩、獨⽴、輕量級通信。微服務架構強調的⼀個重點是“業務需要徹底的組件化 和服務化”。其實這時候就要求服務的拆分達到一個設計原則：單一職責原則。下面我們一起來看看微服務架構下的優缺點
優點：
1、業務聚焦
2、解耦
3、降低團隊合作成本
4、復用性高、可維護性搞
缺點：
由於服務拆分粒度很細，技術成本高（容錯、分布式事務等），對團隊挑戰大、服務治理成本高