單體應用架構
在企業發展的初期，一般公司的網站流量都比較小，隻需要一個應用，将所有的功能代碼打包成一個服務，部署到伺服器上就能支撐公司的業務。這樣也能夠減少開發、部署和維護的成本。
比如，大家都很熟悉的電商系統，裡面涉及的業務主要有：使用者管理、商品管理、訂單管理、支付管理、庫存管理、物流管理等等子產品，初期我們會将所有子產品寫到一個Web項目中，然後統一部署到一個Web伺服器中。
這種架構特點有其優點：
- 架構簡單，項目開發和維護成本低。
- 所有項目子產品部署到一起，對于小型項目來說，維護友善。
但是，其缺點也是比較明顯的：
- 所有子產品耦合在一起，雖然對于小型項目來說，維護友善。但是，對于大型項目來說，卻是不易開發和維護的。
- 項目的各子產品之前過于耦合，如果一旦有一個子產品出現問題，則整個項目将不可用。
- 無法針對某個具體子產品來提升性能。
- 無法對項目進行水準擴充。
正是由于單體應用架構存在着諸多的缺點，才逐漸演變為垂直應用架構。接下來，我們就來看看垂直應用架構。
垂直應用架構
随着企業業務的不斷發展，發現單節點的單體應用不足以支撐業務的發展，于是企業會将單體應用部署多份，分别放在不同的伺服器上。但是，此時會發現不是所有的子產品都會有比較大的通路量。如果想針對項目中的某些子產品進行優化和性能提升，此時對于單體應用來說，是做不到的。于是乎，垂直應用架構誕生了。
垂直應用架構，就是将原來一個項目應用進行拆分，将其拆分為互不想幹的幾個應用，以此來提升系統的整體性能。
這裡，我們同樣以電商系統為例，在垂直應用架構下，我們可以将整個電商項目拆分為：電商交易系統、背景管理系統、CMS管理系統等。
我們将單體應用架構拆分為垂直應用架構之後，一旦通路量變大，我們隻需要針對通路量大的業務增加伺服器節點即可，無需針對整個項目增加伺服器節點了。
這種架構的優點：
- 系統進行了拆分，可根據不同系統的通路情況，有針對性的進行優化。
- 能夠實作應用的水準擴充。
- 各系統能夠分擔整體通路的流量，解決了并發問題。
- 一個系統發生了故障，不應用其他系統的運作情況，提高了整體的容錯率。
這種架構的缺點：
- 拆分後的各系統之間相對比較獨立，無法進行互相調用。
- 各系統難免存在重疊的業務，會存在重複開發的業務，後期維護比較困難。
分布式架構
我們将系統演變為垂直應用架構之後，當垂直應用越來越多，重複編寫的業務代碼就會越來越多。此時，我們需要将重複的代碼抽象出來，形成統一的服務供其他系統或者業務子產品來進行調用。此時，系統就會演變為分布式架構。
在分布式架構中，我們會将系統整體拆分為服務層和表現層。服務層封裝了具體的業務邏輯供表現層調用，表現層則負責處理與頁面的互動操作。
- 将重複的業務代碼抽象出來，形成公共的通路服務，提高了代碼的複用性。
- 可以有針對性的對系統和服務進行性能優化，以提升整體的通路性能。
系統之間的耦合度變高，調用關系變得複雜，難以維護。
SOA架構
在分布式架構下，當部署的服務越來越多，重複的代碼就會越來越多，對于容量的評估，小服務資源的浪費等問題比較嚴重。此時，我們就需要增加一個統一的排程中心來對叢集進行實時管理。此時，系統就會演變為SOA（面向服務）的架構。
使用注冊中心解決了各個服務之間的服務依賴和調用關系的自動注冊與發現。
- 各服務之間存在依賴關系，如果某個服務出現故障可能會造成服務的雪崩（關于穿透、擊穿和雪崩的問題，小夥伴們可以參見我之前寫的《 【高并發】面試官：講講什麼是緩存穿透？擊穿？雪崩？如何解決？ 》一文）。
- 服務之間的依賴與調用關系複雜，測試部署的困難比較大。
微服務架構
随着業務的發展，我們在SOA架構的基礎上進一步擴充，将其徹底拆分為微服務架構。在微服務架構下，我們将一個大的項目拆分為一個個小的可以獨立部署的微服務，每個微服務都有自己的資料庫。
- 服務徹底拆分，各服務獨立打包、獨立部署和獨立更新。
- 每個微服務負責的業務比較清晰，利于後期擴充和維護。
- 微服務之間可以采用REST和RPC協定進行通信。
- 開發的成本比較高。
- 涉及到各服務的容錯性問題。
- 涉及到資料的一緻性問題。
- 涉及到分布式事務問題（小夥伴們可以參見我後續會持續更新的【 分布式事務 】專題）。