架構思考

高可用性有兩個重點，一個是高可靠性，一個是高性能，而為了滿足高性能又引入了架構本身的分布式和高擴展性，由于分布式架構的引入則形成我們常說的CAP理論和問題，即如何解決在高可靠和高性能下的事務和一致性問題，即使不能兼得，那么變通的方式是什么？

架構的高性能，首先要考慮的就是單點的高性能，不要認為引入了分布式和集群技術后就不關注單點本身的性能，很多時候我們的應用即使在相同的硬件環境下，只要我們對程序代碼和數據庫進行相應的優化，性能往往就能夠得到大幅度的提升。因此不要用簡單的資源不足和加集群等簡單理由來為你本身架構和代碼的壞味道買單。

由于在應用服務器層我們很容易通過硬件或軟件技術來實現相應的集群部署，但是在數據庫層往往卻很難，因此對于去IOE架構下其所有的核心都將在數據庫本身實現分布式，是引入完全分布式的數據庫，還是對數據庫進行水平和垂直切分，上面搭建DaaS數據庫服務層。對于Mysql數據庫，在淘寶 corba后現在有了MyCat的開源分布式數據庫版本，對于要搭建高性能分布式架構數據庫的可以考慮采用。

數據庫的垂直拆分的一個重點就是引入組件化開發和架構模式，在前面有篇文章里面剛好已經談到了，例如引入淘寶的Dubbo分布式服務框架，來實現組件化和服務化架構模式。最終要做到的就是每一個業務組件都相當完全獨立，組件的數據庫和應用層都可以做到完全獨立的管理和部署。組件之間只能通過暴露和注冊到Dubbo上的服務進行交互。但是我們看到另外一個問題，即同一個組件本身在技術架構上也是分層的，如包括數據層，邏輯層，服務層和前端展現層。那么一個組件內部的前端和后端是否也需要使用Dubbo服務框架，通過分布式的服務進行暴露和管理，在這里我們的看法是完全沒有必要的，一個組件內部本身的調用走內部服務和API接口調用接口，一方面是這種調用更多都是數據庫表的CRUD操作并發量相當大，一方面是這類接口或服務本身也沒有太大的重用和復用價值。

在引入領域服務的概念后，帶來另外一個問題，即我們的服務層是否需要單獨設計，開發和部署管理。在組件化開發思路里面要注意到，沒有獨立的服務組件，即具體暴露的服務接口本身是包含在業務組件里面的。即一個業務組件里面的接口或方法，通過服務代理機制發布為一個遠程可以訪問的服務。這種思路的核心本身也在于服務組件中的服務本身僅僅是一個代理，而最終的接口實現邏輯還是在原來的技術組件里面。這種設計和實現方法可以最大化的滿足原有技術組件里面的業務邏輯和方法和復用。

那我們究竟是否需要獨立的領域服務組件？根據實際的業務場景和需求可以看到，對于某些場景是需要考慮獨立的領域服務組件的。即在處理具體的業務時候，我們需要調用多個業務組件中暴露的服務，并且對這些服務進行組合形成更加粗粒度的組合服務能力。同時這些組合服務能力本身又不應該歸屬于上層的任何一個業務組件內部，因此在這種情況下我們可以考慮剝離獨立的服務層組件，這種服務層組件的核心目標就是提供獨立的跨組件的領域服務能力，同時又相當獨立。

在引入任何一個新技術或技術組件的時候，都要一開始就想清楚具體面對的業務場景或非功能性需求場景。要明白任何新技術的引入都會增加到這個系統的耦合性和復雜度。包括nosql數據庫，分布式緩存，消息中間件，集群和心跳檢測，全文檢索等各種技術的引入都要一開始就想清楚場景和邊界。只有邊界分清楚了你才可能防止技術被亂用而無法管控。

任何分布式技術的引入可以看到，最讓人頭痛的問題就是這種分布式技術無法做到完全透明，做為一個黑盒子，對于上層業務和應用完全不用考慮底層究竟是否分布式了。這是一種理想情況，當前很多情況是分布式技術無法做到完全透明，導致很多架構約束拋給了上層業務應用開發。例如我們在引入類似corba 分布式數據庫后，對于常規sql語句中的關聯，分組統計都不能很好的做到支持，同時對于分布式事務的支持仍然是一個很大的問題。這也是我們在選擇引入分布式架構和技術務必慎重的原因。

分布式架構的引入另外一個重要思考就是，在一開始構建復雜的分布式架構時候就需要考慮到，這種架構我們在后期能否很好的進行自動化監控和運維。要知道這種架構模式下如果不能真正做到實時的自動化模式下的監控和運維本身就是一個噩夢。即需要在前面談到的高可用性上面再增加一個架構在后期的高可運維性。包括最近我們看到APM比較活，重點也是在解決后期的監控和高可運維性問題。

任何架構的設計都一定是針對具體的業務場景，包括業務場景中的功能需求和非功能性需求，因此對于一個全新的架構設計務必不能簡單的照搬互聯網上的標準模型，而是應該真正根據自身的實際情況進行架構，要說服自己每一個技術點采用的必要性和具體原因。架構重點不是大而全，而是應該小而精；架構重點不是完全彈性和理想化，而是應該適度設計。因為我們看到太多由于架構本身過渡設計導致了整個業務應用設計，開發和運維上諸多的復雜度和困難。

引入DaaS和分布式數據庫后重點要考慮組件怎么劃分，數據庫本身如何進行水平拆分和垂直拆分，組件之間如何進行服務化交互，包括服務化后引入的分布式事務問題如何解決；在引入緩存或分布式緩存機制后重點需要考慮的是緩存本身的同步和刷新機制；引入HA或集群機制后，最難的不是簡單額負載均衡，而是如何通過完整的心跳和檢測機制能夠實時的監控中間件或數據庫服務器的假死現象；在引入了消息中間件后需要考慮本身的異步機制帶來的事務一致性問題，這些都需要在架構設計層面就考慮清楚。

一個架構師就猶如一個摩天大廈的總設計師，雖然大廈還沒有建造完成，但是整個大廈的模型和運轉機制已經深深的印在了心里。架構師在設計中的一個疏忽大意都可能導致業務應用這個大廈頃刻顛覆。一個優秀的架構師可能并不是頂尖的技術天才或狂熱份子，但是他們一定是業務和技術，功能和非功能需求高度融合思考的人。