架構思考續

對于架構設計的思考前面已經寫過不少文章，特別是在互聯網應用出現后在傳統業務系統架構的基礎上增加了新的一些特性和設計思路，該文重點想說明下架構設計的一些演進方向。

組件化開發思路在很早以前就已經提出，只是當時的組件間交互更多的談接口而非服務，同時也沒太關心單個組件本身的全生命周期管理。談組件的時候一定不要先談開發和技術框架，而是真正從業務架構和應用架構出發去考慮整個業務系統的組件劃分，其中包括了業務組件和技術組件，各自應該暴露業務和技術服務能力。業務能力組件化和組件能力服務化也是一直強調的SOA核心思想。

在組件劃分清楚后，需要優先考慮組件間的交互而需要暴露出來的服務接口，即組件之間只能通過服務進行協同以進一步實現組件間的松耦合。其次才是考慮單個組件在實現的時候，結合分層開發技術框架涉及到分層，在這里可以進一步參考領域模型驅動和設計的思路，否則很容易實現為數據庫表驅動功能而不關心領域模型設計和領域邏輯的實現，即雖然技術框架分層了但是職責不清，邏輯混亂并多處實現。

組件內部的實現一個重點就是應用層和領域層之間的關系，即在應用和領域層之間增加了一個服務層，服務層重點是服務接口和服務的組合等工作，而具體業務規則和數據處理的邏輯在倉儲類和規則類里面來實現。注意對于組件內部應用層和領域層交互的服務并不一定要做為分布式的Service服務，也可以直接使用內部的API服務接口即可。將服務層服務接口具體的邏輯實現分離的一個重點就是在后期很容易將服務接口發布為一個供其它組件遠程調用的服務方法。

對于單一的技術往往很難滿足互聯網業務場景下不同的功能需求和非功能性需求，對于不同的功能或技術實現往往都需要選擇大量的開源組件或技術進行集成。但是這些獨立的技術組件如何集成為一個高效的整體就變得相當重要。任何技術的選擇都必須為了業務需求服務，模式分析是選擇技術的一個重點，即在什么樣的業務場景下，面對什么問題我們究竟應該選擇什么樣的開源技術來實現最合適。

首先是開發技術框架層面的，即常說的基于MVC模式的多層框架，用的最多的估計還是SSH框架，其中在數據庫層面又有Hibernate或 iBatis多種實現，在控制層本身又有struts和spring mvc多種實現。在展現層相關的技術點更多，包括了一些前端基于javascript和jquery的框架引入，Ajax實現，包括當前互聯網各種前端響應式框架，Html5技術等。技術框架的選擇看似和業務無關，但是卻需要進行業務場景分析，包括當前開發的應用是否需要同時支撐web端和移動app端，是否存在和外部集成和服務接口暴露，在業務交互和易用性層面有哪些要求，這些都需要考慮進去。

其次是實現核心技術能力的技術組件，其中包括了緩存，消息，流程引擎，搜索，安全，任務，日志等諸多內容，這些當前往往都有現成比較成熟的開源技術來實現。如通過memcached或redis來實現緩存，通過rabbitMQ或zeroMQ來實現消息和事件管理，基于lucence的全文檢索引擎，開源的ETL技術實現數據集成，開源的jbpm流程集成等。在選擇這些技術的時候要注意和前面整體技術框架的集成，技術組件應該保持其高內聚和獨立性，僅僅技術組件的能力通過服務暴露出去實現和上層應用的集成。要做到這一點往往就需要對開源組件進一步進行封裝和定制，以和技術框架形成一個完整的整體，同時又不要把底層技術組件的復雜度暴露給業務功能的開發過程中。還有就是互聯網應用還涉及到外部技術服務能力的引入，如外部的郵件通知服務能力，地圖能力，支付能力，各個外部開放平臺開發的各種內容提供服務能力引入等。對于外部服務能力的引入建議是要在技術平臺層單獨進行管理和封裝，即在技術能力層有獨立和統一的服務代理。

最后是數據庫和持久化層，包括常見的關系數據庫，半結構化和基于key-value的redis，mongoDB等數據庫，還有就是完全基于 hdfs的非結構化文件存儲能力。對于不同的業務場景和業務對象，往往需要底層不同的數據和存儲能力進行支撐，如何形成一個完整能力的數據庫服務能力層是架構設計時候需要考慮的。

去IOE化

對于去IOE化是這兩年互聯網架構設計談得最多的問題，即去掉小型機，集中存儲和商用數據庫。如果簡單來說下去IOE化的核心就是基于開源的類似Mysql數據庫和集群技術，通過X86服務器硬件資源來實現和原來使用IOE架構時候同樣的性能和高可用性。在之前淘寶有開源的corba基于 mysql數據庫來實現分布式數據庫和集群，現在有開源的MyCat來實現，核心就是提供一個DaaS服務層和封裝，來實現高性能和高可用的數據庫中間件產品。

對于去IOE的熱度在當前已經有所下降，這里面有兩個原因一個是本身技術成熟度和CAP原則約束，一個方面的原因就是在去IOE和引入DaaS 數據庫中間件后本身是增加了架構復雜度和應用開發難度。一個方面是由于DaaS層引入導入的分布式事務問題和對于跨庫查詢和Sql語句本身的約束增加。一個是在架構設計中就需要考慮前端業務如何進行組件化，業務對于的數據存儲如何進行分區和分片，究竟如何進行水平拆分和垂直拆分。

可以講在架構設計中的去IOE設計和前面講到的組件化和服務化設計思路密不可分，同時在去IOE下的組件化是徹底的組件化，即組件本身對應的數據庫也是獨立的，組件可以擁有完全獨立的硬件資源和全生命周期管理。因此如果組件沒有劃分，在后期業務功能實現中就可能導致大量的跨庫操作和分布式事務問題。這些都應該在架構設計階段就思考清楚并制定清晰的架構設計約束，任何架構設計都不會有普適性的通用架構存在，架構約束定義是一個架構要發揮其高效能力的關鍵。

首先來看一個最簡單的場景，即客戶和請求端是A，服務提供端是B，對于服務提供端已經實現為了分布式集群即(B1,B2,B3...Bn)，在這種場景下可以看到對于請求會轉發不同的集群節點進行處理。但是對于這種分布式架構來看，集群是可以完全平滑彈性擴展的，但是問題關鍵點在于A的請求究竟應該轉發到哪個B節點去處理，這里面就有一個控制層或管理節點，而對于大多數分布式應用來講管理節點本身是很難集群化擴展的。及時當前很多分布式架構實現過程中已經實現了消息請求和數據傳輸的分離，但是仍然存在對于管理節點無法水平擴展的問題。

對于水平彈性擴展問題的解決，往往會引入集群技術和硬件負載均衡，但是這不是一個完全意義上的去中心化架構，當前我們說的去中心化架構都是沒有統一的管理節點，完全分布式，只有在這種架構下才是完全的去中心化。要做到去中心化就涉及到幾個關鍵點的引入，一個是請求通過sdk包在客戶端的植入進行前移，即客戶端發起請求的時候就已經判斷清楚；其次是對于管理職責后移，即管理端后續重點是從各個集群節點準實時采集數據再進行分析。要實現第二點往往又涉及到高性能的消息中間件的引入。