淺談JavaEE架構演變的風風雨雨 作者：田超凡
版權所有，轉載請註明原作者，仿冒侵權必究法律責任
Level1 傳統架構
就是大家衆所周知的SSM或SSH了，
優點：三層架構職責清晰
缺點：依賴庫管理難度大，協同開發代碼衝突和功能擴展性差，牽一髮動全身。
Level2 Maven聚合架構
對於五花八門的傳統架構框架依賴包，是時候使用Maven進行依賴庫的版本控制和管理了，再也不用到處收集粘貼依賴包了，版本衝突也基於Maven依賴樹快速定位和解決衝突，對於多人開發代碼衝突問題也提出了SVN和GIT作爲集中式和分佈式代碼版本控制
優點：項目依賴庫結構清晰，對依賴庫進行統一管理和維護，極大避免依賴衝突，父子項目和版本控制非常靈活。
缺點：功能仍然過於集中，拆分的只是三層架構中的層而不是業務模塊，多人協同開發難度大，非常容易版本衝突且功能過於耦合，可擴展性仍然沒有得到改善。
Level3 SpringBoot分佈式架構
徹底根據業務模塊和功能對項目進行拆分，對業務模塊單獨拆分後再基於Maven聚合架構按照三層架構原則進行拆分，分佈式項目和項目之間基於Maven傳遞依賴關係實現模塊調用，最終打包成一個項目發佈部署和運行。
優點：職責劃分清晰，不同模塊由不同人員開發，最終統一合併在一起打一個包發佈和部署
缺點：可複用性差，且基於Maven傳遞模塊和模塊之間的依賴關係導致模塊和模塊之間耦合度很高，如果項目業務複雜規模龐大，每個項目模塊還是需要多人協同開發且已經開發的模塊只能作爲最終項目的一個組成部分或者叫一個填充因子，必須最終作爲外部項目的一個組成部分，一旦功能模塊需要進行更加細緻或更多業務完善可能會導致其他模塊也需要做出相應調整，同時如果考慮容災問題，如果一個模塊非常核心也就是引用和被引用非常多其他模塊，一旦這個模塊出現問題將會傳染其他模塊，最終導致整個項目無法正常保持研發進度和發佈進度，而且每個模塊不能單獨拆分，就像鏈表，中間一旦斷開一節，整個鏈表就無法組裝，如果也沒有標準化設計模塊，這一節還只能在這個鏈表上使用，功能完全受限於這個鏈表，不能在其他鏈表複用。
Level4: SOA服務架構
把業務邏輯代碼單獨提取出來並按照業務拆分成多個項目，每個項目就是一個服務，基於rpc遠程調用機制和http協議實現服務之間的相互調用
優點：基於分佈式架構，把每個業務功能模塊定義爲多個平臺，每個業務功能模塊的業務邏輯單獨拆分成項目作爲服務，徹底實現了單一職責功能，且每個服務都有不同的開發人員完成，極大減少了多人協作版本衝突問題，同時服務和服務之間相互獨立，互不干涉，單獨部署和運行，一個服務出現問題不會影響其他服務，也就不會影響平臺和項目的運行，可擴展性，容災性很高，徹底實現高可用。基於註冊中心統一調度和管理服務，服務提供者把服務發佈到註冊中心，服務消費者基於rpc遠程調用機制和SOAP協議通信機制直接訪問註冊中心對應serviceid的服務訪問地址，實現服務和服務之間相互調用，如果按照標準化設計基礎設施和服務接口，服務還可以再劃分爲公共服務和自定義服務，公共服務可以單獨剝離出來使用，提高代碼可複用性。
缺點：隨着軟件規模的日益龐大，一個項目的服務可能也會越來越多，也就導致服務治理逐漸混亂，甚至服務和服務之間依賴關係複雜也會導致服務調度出現問題，如果註冊中心沒有做集羣，一旦註冊中心出現問題，提供者和消費者無法正常運作，項目就會出現無可挽回的嚴重問題，所以對於SOA架構和微服務架構來說，註冊中心搭建的時候一般情況下是必須做集羣的，否則整個服務架構體系就會存在重大隱患。一旦註冊中心出現問題，對於正常運行的項目來說就是毀滅性的打擊，所以也就導致項目發佈和生產，配置，維護成本極高。同時服務日益增加也就導致每個服務的業務功能也會越來越複雜，開發人員職責劃分也會越來越模糊，工作量也會逐漸變成沒有使用SOA架構之前，一夜回到解放前。所以對於大規模和業務複雜的項目，且開發團隊人數比較大的情況下，SOA架構也會出現職責劃分和任務分配不均勻的問題，當然，大廠微服務架構也就應運而生了。
Level5 微服務架構
簡單來說，就是對SOA架構中的服務進行更加細粒度的劃分，把每個服務也拆分成更加詳細的多個子服務，服務和服務之間仍然相互獨立，互不干涉，單獨部署運行，提高開發敏捷性，同時由於微服務架構的負載均衡機制都是在本地基於http協議實現的，所以負載均衡調度更加靈活，本地httpclient只做負載均衡，相比較nginx而言更加輕巧，少了很多條條框框和複雜配置信息，SOA架構和微服務架構都是基於http協議通信，但是區別在於數據傳輸載體，SOA架構是基於SOAP實現，數據載體是XML，但是微服務架構基於REST通信機制實現，封裝了大量的Restful接口，使用json作爲數據傳輸載體。XML和json的傳輸帶寬佔用和數據格式的解析複雜度來比較，很明顯json輕量級數據交換格式更勝一籌，所以微服務架構也使得服務和服務之間調用和通信更加輕便，微服務架構是輕量級的，對於開發任務分配也更加細緻合理，且容災性提到了最高，在SOA架構基礎上更上一層，SOA架構中一個服務壞了不會影響其他服務，但是微服務架構中一個子服務壞了也不會影響一個服務的運行，把微服務出現問題的容災性提到最高，由於粒度更細，所以損傷程度也降到最小，對於大規模軟件系統和開發人員而言，微服務架構是最優解決方案，但是如果軟件系統不是很大且開發成本比較低的情況下，還是推薦SOA架構，因爲微服務架構粒度細，也就導致配置和維護工作量更大，對於一般軟件系統而言，如果使用微服務架構有點頭重腳輕感覺，反而拖慢整體研發進度。微服務架構中首選基於SpringBoot2.0的完整微服務框架SpringCloud提供了完備的一整套微服務處理體系，比如服務治理，動態網關，智能路由等，用來開發微服務架構項目再適合不過了
JavaEE架構演變那些事兒~
20世紀80年代，EJB+JDBC的提出，反響強烈
到20世紀90年代，Spring正式亮相在公衆視野，成爲廣大開發者津津樂道的里程碑，迅速火爆全球JavaEE開發項目
到了21世紀，架構演變速度可以說是光陰似箭，日月如梭，忽如一夜春風來
Spring框架家族新添MVC核心成員：SpringMVC橫空出世，與此同時，面相OGNL的Struts橫空出世，在視圖層框架中，SpringMVC有了競爭對手
ORM框架也告別了JDBC時代，正式開啓IBatis時代，與此同時，推出了純OOP的ORM框架-Hibernate橫空出世，IBatis也有了強勁競爭對手
隨着三層架構概念的提出，這些框架已經不能單獨滿足企業開發需求，所以想到了合作和資源整合，但是每個領域的框架都是勁敵，誰也不願意讓着誰，那這下怎麼辦呢？
Spring就主動站了出來，作爲中間者的角色包容了每個領域的框架，以綠草叢的角色海納百川，包容萬物，MBC框架，ORM框架都集成了進來，所以就演變成兩種組合：
Spring+Struts+Hibernate，即SSH架構
Spring+SpringMVC+MyBatis，即SSM架構
因爲Struts簡便的語法表達式和Hibernate自動生成SQL的方便，SSH迅速佔領開發市場
後來，在實際開發中，越來越多開發者發現Struts安全漏洞百出，並且值棧開銷太大，雖然Struts2進行了修補，但是仍然存在不少安全隱患，再來看Hibernate呢，雖然用起來方便，你可以沒有SQL基礎，但是對你的OOP思想要求是非常高的，隨着項目規模複雜度升級，持久層依賴關係越來越多，Hibernate關聯映射機制經常讓開發者陷入混亂，很難快速定位持久層模塊之間的依賴關係。所以後來，SSH逐漸也退出了JavaEE歷史舞臺
再來看看SSM，則發展的越來越迅猛，首先SpringMVC本身就是從Spring Web模塊抽出來的，繼承了Spring家族先天的優勢-容器化和單例，註解驅動，極大簡化Web層開發流程，代碼簡潔程度一下子提升不少，並且安全性也是十分優越的，除非你質疑Sprin的安全性。IBatis隨着這些年的升級，已經變成了MyBatis，由於MyBatis一直和Spring保持緊密關係，所以跟Spring集成更加方便快捷，雖然要求開發人員有SQL基礎，但是內置了大量標籤元素和註解，可以很方便建立映射關係和關聯關係，並且提供了一系列參數綁定方式，即可以確保高效，又可以保證安全，防止SQL注入。
Spring+SpringMVC+MyBatis迅速以SSM的身份佔領全球開發技術市場，成爲所有JavaEE開發者必備的技能，這一火就火到了現在，基本已經佔領了JavaEE，J2EE傳統架構的所有市場，Spring也已經到了5，6，7代，MyBatis也已經到了2，3代，還有MyBatis-Plus，已經最近很火的lombok註解框架
15年開始，Maven聚合架構初露頭銜，因爲Maven可以使用遠程倉庫，鏡像，本地倉庫管理所有框架的依賴包，並且支持模塊化和父子工程開發，簡化了傳統架構框架搭建難度，在依賴庫管理層面上統一託管，一定程度上保證依賴庫的運行穩定
16年，17年，分佈式架構首次提出，它認爲Maven聚合工程雖然模塊化開發，但是整體還是延續三層架構開發模式，並不能按照功能進行拆分和功能模塊徹底解耦，隨着業務需求複雜度升級，每個項目的功能模塊越來越多，所以分佈式架構就是提倡按功能拆分項目模塊，不同開發人員只需要關注他的模塊開發，對於模塊中有依賴關係的情況，可以使用中間件，Maven依賴建立依賴關係，實現模塊之間既能解耦，又能內聚，典型的好內聚，低耦合設計思想。最後統一整合在一起，構建整個項目和打包發佈。分佈式架構的一站式解決方案-SpringBoot正式亮相在開發者羣體中，提出約定大於配置，簡化Spring框架搭建和使用流程，集成多種starter組件，基本實現即拆即用，SpringBoot迅速成爲分佈式架構首選框架
轉眼來到了17年和18年，SOA架構正式提出，它的口號是一切都是服務，面相服務開發，它提出分佈式架構中存在的問題：各功能模塊之間依賴關係增多，導致一旦哪個模塊出現問題就會牽一髮動全身一旦出現問題也會直接影響其他依賴的模塊正常運行，甚至導致系統崩潰。但是面向服務開發就不一樣，每個功能項目作爲服務進行開發。使用註冊中心來統一進行服務註冊和發現，管理服務和治理服務，提供了容災機制，引入負載均衡的概念來減輕服務器訪問壓力，一旦某個服務出現問題，則可以切換到其他備胎服務（集羣中的其他節點）來迅速替補原服務正常運行，服務和服務之間相互獨立，相互依賴，但是一個服務出問題不會影響其他服務運行，保證整個系統在各種極端情況下能穩定正常運行。隨着SOA架構的出現，面向服務的框架Dubbo/Dubbox迅速出現在廣大開發人員視野，基於RPC遠程調用機制，把服務分爲生產者和消費者，使用註冊中心統一管理和調度服務，成爲SOA架構的核心開發框架。
到了19年，微服務架構提出，SpringCloud全家桶微服務框架正式火熱起來，微服務架構認爲隨着項目體量迅速擴大，對高可用，高併發要求越來越強烈，傳統SOA面向服務架構已經不能解決問題，因此需要對SOA架構中的每個服務進行更加細粒度拆分，使得每塊業務的開發人員能夠更加專注於自己業務模塊的開發，保證開發模塊的高可用，能夠抗住高併發，並且可以迅速進行項目版本迭代。到19年末，SpringCloudAlibaba框架正式亮相在公衆事業，這是一款國人自研發的基於微服務結構的雲原生框架，提倡服務器上雲的概念，整合各種中間件來簡化開發流程，提供了更多集羣實現高可用的選擇方案，對於高併發而言可以使用流量消鋒，接口限流等方式來實現高併發，對於發佈環境和部署環節也提供了一站式自動化解決方案，極大簡化人力物力，逐步引入大數據和機器學習相關技能作爲底層實現的中間件，提倡敏捷開發來實現開發，測試，運維一體化協同工作，極大提高項目設計，開發，部署，發佈全產業鏈各個環節的穩定性，實現高效協同開發，儘可能保證服務在雲上安全，穩定，高效運行。
隨着這些所有經歷的項目架構不同，我深切感受到每個架構在開發過程中不同項目中的核心地位，也逐步從技術越多越好轉變爲技術越精越好，越能符合真實業務場景越好，技術和業務需要有機結合融爲一體。
2019年一年更新兩套架構和開發思想，這也是敲響了警鐘，讓我深刻意識到，技術發展迅猛，不學習，不好好學習，不高效學習，終將都會被淘汰，所以，我們要更加精益求精的打磨技術沉澱，讓技術和業務真正融爲一體，期待技術全球化，數智全民化早日到來，能夠給人們生活帶來更多豐富多彩，提升人類文明發展進程，這不是任務，更不是工作，而是使命，已經深深烙印在內心深處的使命和責任
我相信，並且堅信，祖國和全球的IT事業一定會因爲你我的共同努力發展的越來越好
技術改變生活，代碼照亮現實，加油