可擴展的基本思想：都可以總結爲一個字：拆！就是將原本大一統的系統拆分成多個規模小的部分，擴展時只修改其中一部分即可，無須整個系統到處都改，通過這種方式來減少改動範圍，降低改動風險
按照不同的思路來拆分軟件系統，就會得到不同的架構。常見的拆分思路有如下三種：
面向流程拆分：將整個業務流程拆分爲幾個階段，每個階段作爲一部分。
比如：信息管理學系統的 展示層 → 業務層 → 數據層 → 存儲層
面向服務拆分：將系統提供的服務拆分，每個服務作爲一部分。
比如：將系統拆分爲註冊、登錄、信息管理、安全設置等服務，
面向功能拆分：將系統提供的功能拆分，每個功能作爲一部分
比如：每個服務都可以拆分爲更多細粒度的功能：比如註冊服務、登陸服務、信息管理服務、安全設置服務
從範圍上來看，從大到小依次爲：流程>服務>功能。不同的拆分方式，本質上決定了系統的擴展方式，可以保證證即使程序員出錯，出錯的範圍也不會太廣
1.面向流程拆分：擴展時大部分情況只需要修改某一層，少部分情況可能修改關聯的兩層，不會出現所有層都同時要修改。例如學生信息管理系統，如果我們將存儲層從MySQL擴展爲同時支 持MySQL和Oracle，那麼只需要擴展存儲層和數據層即可，展示層和業務層無須變動。
2.面向服務拆分：對某個服務擴展，或者要增加新的服務時，只需要擴展相關服務即可，無須修改所有的服務。同樣以學生管理系統爲例，如果我們需要在註冊服務中增加一種“學號註冊”功能，則只 需要修改“註冊服務”和“登錄服務”即可，“信息管理服務”和“安全設置”服務無須修改。
3.面向功能拆分 對某個功能擴展，或者要增加新的功能時，只需要擴展相關功能即可，無須修改所有的服務。同樣以學生管理系統爲例，如果我們增加“學號註冊”功能，則只需要在系統中增加一個 新的功能模塊，同時修改“登錄功能”模塊即可，其他功能都不受影響。
不同的拆分方式，將得到不同的系統架構，典型的可擴展系統架構有：
面向流程拆分：分層架構（分層架構的本質，就是固定的內核，移動的數據）
面向服務拆分：SOA、微服務
面向功能拆分：微內核架構(插件式架構)
上述的架構是可以在系統架構設計中進行組合使用的。
1、整體系統採用面向服務拆分中的“微服務”架構，拆分爲“註冊服務”“登錄服務”“信息管理服務”“安全服務”，每個服務是一個獨立運行的子系統。
2、其中的“註冊服務”子系統本身又是採用面向流程拆分的分層架構。
3、“登錄服務”子系統採用的是面向功能拆分的“微內核”架構。
總結分析：因爲本人主要負責的是規則引擎的部分，分析後可以得出，肯定不是分層架構，即不是面向流程的，因爲規則引擎主要作用在業務層。其次，也不應該是面向服務的，因爲規則引擎都是跨越多個服務的。 規則引擎和插件式架構，解決的都是功能擴展的問題。微內核架構就是一種插件式架構。（擴展：規則引擎由推理引擎發展而來，是一種嵌入在應用程序中的組件，實現了將業務決策從應用程序代碼中分離出來，並使用預定義的語義模塊編寫業務決策。接受數據輸入，解釋業務規則，並根據業務規則做出業務決策）
分層架構和SOA：
分層架構：是很常見的架構模式，它也叫N層架構。例如，C/S架構、B/S架構。常見的是3層架構（例如，MVC、MVP架構）
. C/S架構、B/S架構：劃分的對象是整個業務系統，劃分的維度是用戶交互，即將和用戶交互的部分獨立爲一層，支撐用戶交互的後臺作爲另外一層。
是C/S架構結構圖
MVC架構、MVP架構
分層架構設計最核心的一點就是需要保證各層之間的差異足夠清晰，邊界足夠明顯，讓人看到架構圖後就能看懂整個架構，分層時要保證層與層之間的依賴是穩定的，才能真正支撐快速擴展。分層架構之所以能夠較好地支撐系統擴展，本質在於隔離關注點，即每個層中的組件只會處理本層的邏輯。
分層結構的另外一個特點就是層層傳遞，也就是說一旦分層確定，整個業務流程是按照層進行依次傳遞的，不能在層之間進行跳躍。所以導致分層架構典型的缺點就是性能，因爲每一次業務請求都需要穿越所有的架構分層，有一些事情是多餘的，多少都會有一些性能的浪費。
面向服務的架構 SOA：
SOA出現的背景是企業內部的IT系統重複建設且效率低下，主要體現在：
1、企業各部門有獨立的IT系統，隨着業務的發展，複雜度越來越高，更多的流程和業務需要多個IT系統合作完成。
2、各個獨立的IT系統實現技術不同，企業自己也不太可能基於這些系統進行重構。
SOA的3個關鍵概念：
服務：所有業務功能都是一項服務，服務就意味着要對外提供開放的能力，當其他系統需要使用這項功能時，無須定製化開發。
ESB：將企業中各個不同的服務連接在一起。SOA使用ESB來屏蔽異構系統對外提供各種 不同的接口方式，以此來達到服務間高效的互聯互通。
松耦合：目的是減少各個服務間的依賴和互相影響。因爲採用SOA架構後，各個服務是相互獨立運行的，甚至都不清楚某個服務到底有多少對其他服務的依賴。如果做不到松耦合， 某個服務一升級，依賴它的其他服務全部故障，這樣肯定是無法滿足業務需求的。
總結：SOA解決了傳統IT系統重複建設和擴展效率低的問題，但其本身也引入了更多的複雜性。SOA最廣爲人詬病的就是ESB，ESB需要實現與各種系統間的協議轉換、數據轉換、透明的動態路由等功能、工作量和複雜度都很大，而且這種轉換是需要耗費大量計算性能的，當ESB承載的消息太多時，ESB本身會成爲整個系統的性能瓶頸
背景：SOA的ESB設計也是無奈之舉，SOA的提出背景就可以發現，企業在應用SOA時，各種異構的IT系統都已經存在很多年了，完全重寫或者按照統一標準進行改造的成 本是非常大的，只能通過ESB方式去適配已經存在的各種異構系統。
面向服務的架構 微服務：
微服務與SOA的關係：
相似點在於兩者都關注“服務”，都是通過服務的拆分來解決可擴展性問題。本質上不同的地方在於幾個核心理念的差異：是否有ESB、服務的粒度、架構設計的目標等。
1. 服務粒度（依賴服務治理系統）
對一個大型企業來說，“員工管理系統”就是一個SOA架構中的服務；而微服務架構，則“員工管理系統”會被拆分爲更多的服務，比如“員工信息管理”“員工考勤管理”“員工假期管理”和“員工福利管理”等更多服務。
2、服務通信（依賴於RESTful API, RPC）
SOA採用了ESB作爲服務間通信的關鍵組件，負責服務定義、服務路由、消息轉換、消息傳遞，總體上是重量級的實現。微服務推薦使用統一的協議和格式，例如，RESTful協 議、RPC協議，無須ESB這樣的重量級實現， 傳統SOA架構最廣爲人詬病的就是龐大、複雜、低效的ESB。
3、服務交付（依賴敏捷開發技術(自動化測試,持續集成,自動化部署)）
SOA只考慮兼容已有系統，幾乎不考慮交付需求，微服務的架構理念要求“快速交付”，相應地要求採取自動化測試、持續集成、自動化部署等敏捷開發相關的最佳實踐（如果沒有這些基礎能力支撐，微服務規模一旦變大（例如，超過20個微服務），整體就難以達到快速交付的要求，這也是很多企業在實行微服務時踩過的一個明顯的 坑，就是系統拆分爲微服務後，部署的成本呈指數上升。）
4、應用場景
SOA更加適合於龐大、複雜、異構的企業級系統，典型特徵就是很多系統已經發展多年，採用不同的企業級技術
微服務更加適合於快速、輕量級、基於Web的互聯網系統，這類系統業務變化快，需要快速嘗試、快速交付，同時基本都是基於Web，雖然開發技術語言可能不同，但對外接口基本都是提供HTTP RESTful風格的接口，無須考慮在接口層進行類似SOA的ESB那樣的處理。
small、lightweight、automated，基本上濃縮了微服務的精華，也是微服務與SOA的本質區別所在
微服務的缺點：
1、服務劃分過細，單個服務的複雜度確實下降了，但整個系統的複雜度卻上升了，因爲微服務將系統內的複雜度轉移爲系統間的複雜度。整體系統的複雜度是隨着微服務數量的增加呈指數級增加的。
2、.服務數量太多，團隊效率急劇下降，一個需求涉及多個服務。是設計、開發、測試、部署，都需要工程師不停地在不同的服務間切換。
3、調用鏈太長，性能下降，（微服務之間都是通過HTTP或者RPC調用的，每次調用必須經過網絡。一般線上的業務接口之間的調用，平均響應時間大約爲50毫秒，如果用戶的一起請求需要經過6次微服務調 用，則性能消耗就是300毫秒，這在很多高性能業務場景下是難以滿足需求的。爲了支撐業務請求，可能需要大幅增加硬件，這就導致了硬件成本的大幅上升)
4、 調用鏈太長，問題定位困難，一次用戶請求需要多個微服務協同處理問題定位難，我們公司）在這方面上得益於強大的服務追蹤系統也就是trace日誌，後期我會進行深入研究寫一篇文章進行詳述，每個rpc請求都有相對應的日誌，定位問題使其快速、便捷
5. 沒有自動化支撐，無法快速交付（有自動化測試、自動化部署、自動化監控）
6. 沒有服務治理，微服務數量多了後管理混亂
主要問題有：
服務路由：假設某個微服務有60個節點，部署在20臺機器上，那麼其他依賴的微服務如何知道這個部署情況呢？
服務故障隔離：假設上述例子中的60個節點有5個節點發生故障了，依賴的微服務如何處理這種情況呢？
服務註冊和發現：同樣是上述的例子，現在我們決定從60個節點擴容到80個節點，或者將60個節點縮減爲40個節點，新增或者減少的節點如何讓依賴的服務知道呢？
如果以上場景都依賴人工去管理，整個系統將陷入一片混亂，最終的解決方案必須依賴自動化的服務管理系統，這時就會發現，微服務所推崇的“lightweight”，最終也發展成 和ESB幾乎一樣的複雜程度。
面向功能架構：微內核架構（插件化架構）
是一種面向功能進行拆分的可擴展性架構，通常用於實現基於產品的應用
1、基本架構
微內核架構包含兩類組件：核心系統和插件模塊。核心系統負責和具體業務功能無關的通用功能，例如模塊加載、模塊間通信等；插件模塊負責實現具體的業務邏輯
微內核的架構本質就是將變化部分封裝在插 件裏面，從而達到快速靈活擴展的目的，而又不影響整體系統的穩定。
微內核的核心繫統設計的關鍵技術有：
插件管理：核心系統需要知道當前有哪些插件可用，如何加載這些插件，什麼時候加載插件。常見的實現方法是插件註冊表機制
插件連接：常見的連接機制有OSGi（Eclipse使用）、消息模式、依賴注入（Spring使用），甚至使用分佈式的協議都是可以的，比如RPC或者HTTP Web的方式。
插件通信：雖然設計的時候插件間是完全解耦的，但實際業務運行過程中，必然會出現某個業務流程需要多個插件協作，這就要求兩個插件間進行通信。由於插件之間沒有直接聯繫，通信必須通過核心系統，因此核心系統需要提供插件通信機制。
規則引擎架構簡析：規則引擎從結構上來看也屬於微內核架構的一種具體實現，其中執行引擎可以看作是微內核，執行引擎解析配置好的業務流，執行其中的條件和規則，通過這種方式來支持業務的靈活多變。規則引擎在計費、保險、促銷等業務領域應用較多
好處：1、可擴展，充分與業務系統解耦 2、容易理解 3、高效率，方便RD快速配置新的業務