java技術的發展

在java開始流行起來之后，主要服務于企業家應用，例如ERP,CRM等等，這些項目是為企業內部員工使用，我們的思維是怎么用設計模式，如何封裝代碼。讓開發人員關注到業務上去，系統也就那么幾十幾百號人用。

隨著互聯網的興起，原本都是用PHP做的應用，隨著互聯網應用的業務復雜度，用戶體量的增加，越來越不實用。然后開發語言開始轉向java。

在2010年左右的盛行S2SH(struts2、spring、hibernate)，隨著互聯網應用的深入，struts2在互聯網部署的時候有嚴重的安全性問題，hibernate雖然有二級緩存這些設置，但是hql不是原生sql很難優化等問題，技術開始使用springmvc、spring、mybatis。

再隨著用戶體量的不斷增加和業務的復雜程度的提升，淘寶開始使用dubbo的RPC框架，然后發展到springboot和springcloud的出現。我們漸漸的在互聯網公司中引入分布式框架，直到分布式技術的漸漸成熟。

因為有需求，技術才不斷的發展。技術都是方便業務需求的發展的。

業務復雜度的提高和用戶體量的增加需要我們分布式如何應對

隨著業務復雜度的提高，我們如果還是把程序維護在一個項目里面，不管是實體類的增加，JVM類加載的問題，性能的問題，項目復雜度的問題，這個時候需要我們對項目的復雜度進行拆解，也就是我們技術中說到的垂直拆分，隨著我們在對整個系統進行拆分的時候遇到實際部署中遇到的一些問題，我們總結出DDD領域建模的方法論

隨著用戶體量的不斷增加，我們的并發也在不斷的升高。關于用戶體量的增加，我們數據庫的存儲也隨著增加，當一張表中數據量過大，我們在查詢的時候，就會增加磁盤搜索的時間成本，造成一個查詢很長時間出不來。為了不會在同一張表中放置大量的數據，我們需要分表的操作。最開始的時候的分布式，大約在12年13年這樣我們都是對數據的主鍵或者對數據進行hash計算，求模分到不同的表中，但是這種行為代碼的侵入性太大，后來出了mycat,但是mycat對求笛卡爾交集還有別的一些問題，在分庫情況下求交集上經常遇到問題，后來出了springjdbc，然后慢慢的也流行起來了。這個是我們分表的問題。

那么隨著用戶體量的增加，大量的訪問進入到我們的系統。我們知道數據庫去執行sql語句的時候，是通過引擎程序執行的。執行引擎也是有性能瓶頸的，這個時候就需要考慮分表的問題了。

單體服務的問題

1. 擴展的問題
   單體的服務架構通過前端的負載均衡后部署多個實例進行擴展。如果需要對特定的功能進行擴展，我們只能通過多部署服務進行擴展。這樣會造成資源的大量浪費。如果是基于微服務部署只需要對特定的功能進行擴展，其他服務實例不需要擴展，比較靈活。

2. 交付時間長
   

單體的服務在業務變更的時候需要構建和部署整個服務，開發人員需要下載整個應用程序進行修復和測試。而微服務只需要修改微服務的部分并部署對應的服務即可，不會影響其他服務的運行。

3. 單體服務應用的復雜性
   隨著應用的業務功能的擴展，團隊也需要不斷的擴張，各種復雜的業務會交織在一起，造成項目的臃腫，維護起來會越來越麻煩，最后修復功能的時候牽一發而動全身，系統很難維護。在微服務的架構中，每個服務獨立負責自己的業務。每個服務的業務域劃分清楚以后，維護起來會清爽很多。

4. 代碼依賴和團隊協作的問題
   傳統的開發模式，我們劃分的團隊看起來是獨立的但是他們在相互的協作的過程中有嚴重的代碼上依賴的問題，團隊中相互依賴造成大量工作上的浪費。微服務架構團隊之間彼此獨立，獨立的團隊負責獨立的業務，工作明確。包括開發部署和監控。

5. 應用服務故障的關聯
   在一個單體服務，如果在交付過程中，一部分程序出現問題會造成整個服務的不可用

6. 陷入某種語言的禁錮
   由于單體服務是一個整體的項目，所以使用都是同一種開發語言。隨著業務的發展，如果某種語言并不能勝任，則需要整體的重構，造成大量資源的浪費，特別是一些大型系統的整體重構是很大的工作量