隨着信息時代的爆炸，應用場景的變化，傳統架構無法滿足互聯網高速迭代變化的業務場景中，故演化出了互聯網架構。架構是隨着業務場景變化而演化的，不以業務場景為架構的架構，是銀彈的架構。架構只有合適與不合適，沒有絕對的好和壞，架構的本質其實是解決軟件復雜度帶來的問題。
我們再來看看傳統架構的演變過程，在JSP的時代，所有邏輯一伙色捅到JSP里面，界面的展示，業務邏輯的處理，數據庫的連接處理等操作，開發者剛開始是爽了，什么都不管從早到黑一伙色很愉快的寫到底，到后來軟件的迭代，需求的增加，才發現代碼是多么的難維護。改一發而動全身，另外測試回歸成本高，為了解決這些操蛋的問題帶來的煩惱，MVC架構模式橫空出世。
MVC架構：
即：Controller、View、Model三個角色各司其職，降低軟件復雜度。各個角色有很明確的職責，即View只負責界面層的展示，Controller只負責請求，Model只負責業務邏輯的處理。MVC適用場景單個業務子系統，划分的維度是職責，將不同職責划分到獨立層，但各個層的依賴關系比較靈活。例如下圖：
分層架構：
但隨着軟件復雜度的提升，業務場景的變化又出現分層架構模式，可以分3層甚至多層，無論采取何種的分層維度，分層架構設計最核心的一點就是需要保證各層之間的差異足夠清晰，邊界足夠明顯，另外分層架構能較好的支撐系統擴展性，例如：展現層只需要處理展示層的邏輯，業務層只需要處理相關的業務邏輯，這樣我們在擴展某層的時候，其他層不受影響，例如：需要調用第三方API，這時我們只需要加一個專門用來處理調用第三方API的集成層。分層架構應用場景可以是單個業務系統，也可以是子系統。典型的分層架構如下圖：
SOA架構：
什么是SOA？SOA是面向服務體系的架構。SOA更多的是在傳統企業（例如：制造業），之前我所在的公司在SOA方面的落地比較多。例如：MDM主數據管理，ESB中間件打通企業內部各業務系統實現互連互通。SOA出現的背景是企業內部IT系統的重復建設且效率低下，主要體現在隨着業務的發展，復雜度越來越高，更多的流程和業務需要多個業務系統合作完成。由於各個業務系統沒有標准的實現方式，例如：OA系統用JAVA實現，MES系統用C#實現，BOM系統用PHP實現，另外各系統對外暴露接口的協議也參差不齊，有SOAP、HTTP、RPC、JMS、WS等。每次開發新的流程和業務，都需要協調大量的業務系統，同時定制開發，效率很低。
為了應對傳統IT系統存在的問題，SOA提出了面向服務體系的開發，即組件化，服務化，通過ESB來進行異構系統之間的互連互通。ESB全稱是“企業服務總線”。ESB將企業各個不同的服務連在一起。因為各個獨立的服務是異構的，如果沒有統一的標准，則各個異構系統對外提供的接口是各式各樣的。SOA使用ESB來屏蔽異構系統對外提供各種不同的接口方式，以此來達到服務間的搞笑的互連互通。
SOA架構是比較高級的架構設計理念，一般情況下我們可以說某個企業采用了SOA架構來構建IT系統，但不會說某個獨立的業務系統采用了SOA的架構。SOA解決了傳統IT系統重復建設和擴展效率低問題，但其本身也引入了更多的復雜性。ESB是厚重的，ESB需要實現與各種系統間的協議轉換，數據轉換，透明的動態路由等功能。ESB本身也會成為整個系統的性能瓶頸。典型的SOA架構圖如下：
微服務架構：
隨着互聯網信息爆炸的時代，傳統的架構已無法支撐互聯網應用，互聯網應用特點：高並發，可擴展，可伸縮，高可用，敏捷，安全等特點。隨着而來微服務框架Dubbo，SpringCloud來勢凶猛。尤其是近兩年SpringCloud發展迅猛。提供了一系列全家桶開發框架。服務治理、服務注冊、服務發現、客戶端負載均衡、API網關、監控等功能。