.Net 分佈式雲平臺基礎服務建設說明概要

1）  背景

建設雲平臺的基礎框架，用於支持各種雲服務的業務的構建及發展。

2）  基礎服務

根據目前對業務的理解和發展方向，總結抽象出如下幾個基礎服務，如圖所示

 

3）  概要說明

基礎服務的發展會根據業務的發展，調整和完善，也會不斷的改進，演變及完善；固然根據目前公司的現狀和對基礎服務的迫切程度，基礎服務各模塊的定位和發展預期將以下所述。

1）     數據庫中間件

公司現狀：

1）     對多種類型數據庫的支持需求迫切，如同時支持mysql，orcale，sqlserver這些數據庫。最多改動少許代碼就能夠在多種數據庫類型中切換。

2）     儘可能不要讓開發人員寫sql代碼，由於原有的開發人員開發方式是採用linq的方式，大部分開發的業務是winform類型的業務。

採用方案：

目前採用entity framework，因entity framework 自己採用linq方式編程，自身可以解析linq爲sql，且兼容多種數據庫類型的查詢。Entity framework 在.net 中的流行程度較高，代碼開源，版本發展較快，且擁有大量應用文檔和學習資料，相比較同類型的框架而言，當首選之。

方案弊端：

Entity framework 的採用只是臨時的方案，由於業務的須要會持續比較久的時間。

1）     從高性能的服務來看，linq to sql的過程必然會有性能損失，即使框架作了解析的緩存，可是也沒法避免這些問題。一些複雜語句的查詢，linq to sql 目前也會出現意外的解析結果，複雜的語句查詢難以用linq表達。若是不是對linq to sql 這種方式較熟練和關注性能的人，通常寫法上也會致使性能問題。

2）     從數據庫的角度看，目前業務暫時還使用同一個數據庫，將來業務會採用多個數據庫，多張數據表。這一點entity framework 後面會涉及到分庫的支持和分表的支持，顯然即使修改源碼也很頭疼。並且多個數據源，多個數據庫類型的支持，意味着同一個業務要涉及到多種數據庫下面性能的調優和運維，特別是涉及到版本升級的數據遷移，要兼容多種數據庫，意味着工做量真心不小。

將來方向：

採用單一類型的數據庫，會有一個支持sql編寫直連數據庫，支持分庫分表的分佈式數據庫，自動管理數據庫鏈接池，自動提供性能分析及預警等的數據庫中間件。

 

2）     TCP服務框架

公司現狀：

1）     用於採集程序，採集設備和服務器的直連，發送採集信息。

2）     服務器端反向通知鏈接程序或設備，即時通知信息。

3）     與工做站的通訊環境（雲平臺採用ActiveMQ）,鏈接第三方設備（採用signalr asp.net）。

採用方案：

暫時保持與工做站的通訊環境（雲平臺採用ActiveMQ）,鏈接第三方設備（採用signalr集成入asp.net）這種方案。由於公司目前採用C#編程，這兩塊技術選型都有相應的C#客戶端或者C#的解決方案的一些示例；故使用起來問題應該不大，可是遇到的問題也不會少。若遇到性能問題，能夠簡單的經過擴展多個ActiveMQ和 應用服務的負載均衡來解決。

其餘方案：

採用redis或者rabbitmq之類的相似解決方案，我的傾向與redis 的發佈訂閱機制解決，性能不算差（聽聞過上規模的使用案例及跨語言客戶端sdk）（且能夠統一緩存的使用框架，便於維護。）

方案弊端：

1）     不管採用redis，activemq，rabbitmq之類的哪一種消息隊列方式解決，都沒法避免本質的性能問題，由於這些框架自己是用來解決消息隊列的，由於其內存消息轉發機制，故而用於一些即時通信，經常使用於解決內網環境的一些應用交互。目前的場景會應用到廣域網環境與工做站進行通訊，業內相似的解決方案也曾有人使用過，可是也會常常出現activemq 內存滿或者莫名死掉的狀況。

2）     採用signalr 應用掛載到asp.net 上面的使用方式，通過一些第三者開發的經驗，也會出現稍微高併發就出現性能問題或者死掉的狀況。Signalr 經常使用於.net 技術，也有簡單的使用案列，可是尚未成熟的上規模的使用案例和場景。

將來方向：

採用java的NIO思想或者Windows 完成端口思想,搭建純粹的TCP socket服務是解決本質的一個方案，通常一臺服務器可以承載10萬的鏈接，幾千的活動鏈接（具體看服務器配置等狀況）不會有問題（而舊方案可能承載幾千，上百的活動鏈接就會出現性能問題）。

 

3）     認證中心

公司現狀：

1）     原有工做站內網子系統的登錄驗證，外網設備登陸驗證，雲平臺用戶登陸驗證。

2）     雲平臺用戶菜單權限獲取，操做權限獲取。

採用方案：

自行研發公司特有業務的認證中心平臺，目前僅第一個版本。包含

1）     設備管理，子系統管理，雲平臺用戶管理和權限管理等

2）     第三方使用的登陸接口，用戶菜單權限接口，用戶操做權限接口。

以上功能目前可以知足現有公司的業務。

方案弊端：

1）     目前比較簡單，經過token受權，無名加密，無appid和serect祕鑰受權之類的。故而沒有較強的安全機制，可是可以知足實際開發。並且目前的公司業務對於安全的要求並不高。

2）     通訊性能不高，由於目前採用Http協議進行通訊，自己通訊性能不高。並且認證中心將承載全部業務的認證，基本上全部雲項目模塊等業務都會將請求匯聚到認證中心的接口上，在後續公司流量的發展上必然會出現第一個出現接口上的性能問題。

將來方向：

1）     平臺全部的接口實現內部必須有redis緩存，平臺接口客戶端使用要有sdk封裝（在sdk內部作客戶端緩存，哪怕默認5 s的緩存）

2）     平臺的全部接口後續接到「高性能服務中心」，走TCP鏈接池的通訊方式實現，提升內部通訊的性能。

4）     服務中心（我的開源地址：http://git.oschina.net/chejiangyi/Dyd.BaseService.ServiceCenter）

公司現狀：

1）     項目之間出現互相調用的業務耦合，目前採用dll的方式調用，可是出現dll更新出錯及管理等狀況，致使開發人員認爲效率不高。

2）     公司迫切但願採用微服務/soa的架構方式來剝離項目的業務耦合，簡化上下游業務調用的管理方式。

採用方案：

1）     暫時採用Http restful相似的方式提供服務化的接口，供第三方接口調用，同時這也符合soa服務化的架構思想。

2）     經過api view 自動公開接口文檔，上下游之間調用調試，方便開發人員溝通協調。

方案弊端：

1）     我的經驗：服務化的接口方式有效的,對業務溝通也是很是有幫助的，可是未必可以真正的在效率上獲得本質的提高。可是對於項目的模塊化管理應該有較好的幫助。

2）     Http的接口通訊方式效率並不高，做爲服務框架必然是走TCP的內部通訊，性能纔會有明顯提高。

3）     服務治理，協調方面的問題爲考慮，如沒有考慮調用鏈死循環，調用鏈上的性能致使雪崩，上下游服務監控，上下游客戶端服務變動歷史記錄及通知，上下游客戶端服務協議耦合剝離，服務化層面的負載均衡和故障轉移等等衆多問題。

將來方向：

1）     自研服務中心，將性能，服務治理，協調等工做從業務開發中抽離抽象出來，業務開發只須要關注無狀態的業務服務開發便可。

2）     全部內部的業務所有剝離（不只僅是耦合的業務），遷移到內部的服務中心，若是內部服務須要對第三方公開，能夠提供Http的開放網關服務進行調用，網關層會作一些受權管理等工做，網關自身作負載均衡。

5）     統一監控（我的開源地址：http://git.oschina.net/chejiangyi/Dyd.BaseService.Monitor）

公司現狀：

1）     項目處於前期研發階段，沒有較大規模的服務器集羣，沒有遇到多版本接口兼容，沒有遇到線上監控問題和線上排查問題，性能問題的痛苦，對這些狀況還不瞭解和敏感。

2）     開發人員但願解決項目開發調試時候，錯誤日誌及錯誤日誌的堆棧問題，調用路徑問題排查。

採用方案：

1）     採用Http Restful 服務化業務接口的方式，應該能緩解項目開發調試的問題。（開發調試問題之前沒遇到過，應該跟原來架構和技術採用wcf等方式有關致使）

2）     搭建分佈式監控平臺，由於是本人已有開源的項目，使用起來問題不大。可以解決不少雲上服務器管理，性能監控及預警，sql性能監控，api接口性能監控，統一錯誤日誌等。

方案弊端：

1）     我的還不是特別確切瞭解目前項目開發人員調試項目開發過程當中，對日誌問題真正迫切的本質緣由，也沒深入體驗（一直開發以來沒有遇到問題難調試的問題，可能現有公司項目架構方式關係密切），因此不知道是否可以解決。

2）     目前分佈式監控平臺是在原有公司開發的簡化版本，爲了實現總體項目架構的監控那塊的抽象和佈局而研發的。性能和功能上還有不少的優化和改進空間。（固然支持公司的現狀仍是綽綽有餘）

將來方向：

1）     根據公司的業務對監控的需求，還須要不斷的改進和完善監控平臺。

2）     監控平臺的功能和性能須要完善，底層將使用nosql來存儲實現。

6）     配置中心（我的開源地址：http://git.oschina.net/chejiangyi/Dyd.BaseService.ConfigManager）

公司現狀：

1）     目前公司有相似配置中心的功能，用於基本的業務配置的使用，比較簡單。

2）     雲這塊業務尚處於簡單的業務模型和業務狀態，未遇到真正線上複雜的業務和業務剝離的需求，及異步化的功能點，統計類的功能等等，對分佈式配置中心的本質需求和問題尚未真正暴露出來。

採用方案：

依舊使用原有的配置中心功能，同時分佈式的配置中心也會搭建。原有的配置中心適合業務配置的存儲，現有的配置中心能夠用於業務配置的存儲，也能夠用於分佈式架構的環境配置協調問題。

方案弊端：

會維持兩套配置中心的運維，在業務架構上比較難以區別，業務上容易混亂。

將來方向：

1）     兩塊配置中心將根據業務的需求和方向，在必定程度上進行融合。但就目前的公司精力不會着重這塊。

2）     配置中心將根據公司的業務發展，也會繼續演變出更多的功能，不過暫時不明朗。

7）     消息隊列（我的開源地址：http://git.oschina.net/chejiangyi/Dyd.BusinessMQ）

公司現狀：

1）     目前公司在雲平臺端與工做站異步通訊是經過ActiveMQ進行的。

2）     雲平臺項目還處於前期研發起步階段，業務複雜度還不夠，對性能的要求不高，也未涉及同一業務異步化拆分和解耦。

3）     公司的採集方面的業務還未作到真正的大規模分析，大規模採集的場景。

採用方案：

出於公司架構統一的現狀考慮，暫時採用ActiveMQ，也方便java，C#等跨語言的異步通訊。固然也僅僅能應用與異步化的簡單的即時通訊效果。

方案弊端：

ActiveMQ 只能做爲異步的即時通訊暫時使用，就目前的性能和穩定性來講，並非長遠之計。

1）     如果爲了持久化的Tcp通訊，將來本身會有TCP服務的搭建來確保。

2）     如果爲了消息隊列的通訊，將來更多考慮消息的堆積性能，消息的高穩定性和高可靠性（不能丟失消息）。

3）     如果考慮消息隊列收集消息便於後續採集分析，將來更多考慮相似kafka的方案。

將來發展：

消息隊列有衆多的解決方案，也有衆多的一些特性適用於不一樣的業務場景。針對這些不一樣的場景和方案，我的會作以下考慮：

1）     自建的一套消息隊列平臺，自建的消息隊列能夠剝離底層的存儲引擎，經過不一樣的存儲引擎的特性，達到適用不一樣場景和方案的目的。（如存儲引擎爲redis，ssdb，數據庫等，即使實現邏輯相同，可是性能不一樣，可靠性表現也不一樣）

2）     自建的一套消息隊列中間件，能夠剝離具體的消息隊列實現，抽象出常規消息隊列的使用方式。僅經過修改鏈接字符串或者配置類，就能實現不一樣消息平臺的切換。（如底層消息服務多是activemq，rabbitmq，redis，kafka，對上層業務能夠是透明，甚至無縫切換）

8）     任務調度平臺（我的開源地址：http://git.oschina.net/chejiangyi/Dyd.BaseService.TaskManager）

公司現狀：

1）     公司目前業務尚處於前期，未有業務需求有相似後臺任務統計，後臺任務消費之類的業務需求。

2）     任務調度平臺是全部基礎服務的一個基礎環節，目前也僅在基礎服務部署中使用。

採用方案：

我的開源的分佈式任務調度平臺。

方案弊端：

分佈式任務調度平臺目前僅屬於一個簡單的任務調度平臺，將來的發展方向還有很大的空間。

將來發展：

1）     全部公司的業務都被視爲一個業務任務，全部的業務任務都將被掛載到任務調度平臺，任務調度平臺會根據分佈式集羣的負載狀況，自動分配集羣服務器用於業務的負載均衡和故障轉移等資源的調度和協調。（如全部的接口服務，全部的後臺任務，全部的消息消費任務等等）

2）     任務調度平臺也可稱爲相似於hadoop之類的大數據處理，實時計算平臺，用於批量處理實時的，非實時的一些動態的流式的任務建立，回收，協調。（如相似爬蟲之類的採集業務，和算法分析任務等）

9）     分佈式緩存（我的開源地址：http://git.oschina.net/chejiangyi/XXF.BaseService.DistributedCache）

公司現狀：

1）     目前公司的業務還不須要用到分佈式緩存的使用，除了認證中心這塊應該在後續涉及到一些性能問題。

採用方案：

我的開源的分佈式緩存中間件。（目前實現的是基於memcached協議的一個統一的分佈式緩存框架）

方案弊端：

僅支持基礎的分佈式緩存框架，總體數據結構比較簡單（key+定時過時失效），可是也是緩存中最實用的功能。

將來發展：

1）     支持更多的協議，如redis的通訊協議。及更多底層存儲框架的抽象。（每種緩存框架都有特定的使用場景和微妙的差異）

2）     分佈式緩存的統一性能監控；一致性哈希的支持便於實現定製的故障轉移方案，避免雪崩等緩存失效場景。

3）     根據公司的業務支持其餘緩存場景，如本地緩存一致性（協同分佈式消息隊列實現）的支持。

10）  文件服務

公司現狀：

1）     公司目前的採集的業務將信息都存在本地的應用服務器，以文件形式存儲。

2）     公司的採集業務信息文件，須要持久保存。

採用方案：

暫時保持現狀。

方案弊端：

1）     不管從容量的擴容和性能的角度看，單獨的文件服務器是一個長遠的必然需求。

2）     目前的業務可能涉及到文件的連續存儲和文件部份內容的讀取的需求，就市面上的開源文件服務可能不知足需求。

3）     我的如今對公司關於文件服務的業務需求，還不是特別瞭解。

將來發展：

1）     考慮自研分佈式文件服務，讀取性能未必勝於市面的開源文件服務。（自研的文件服務應該仍是基於windows文件管理結構），可是靈活度會更高。

2）     自研的分佈式文件服務sdk，要在使用上抽象，併兼容公司的底層存儲差別（有些大文件存儲可能仍是使用第三方存儲，可是對於開發來講是透明無感知的）。

11）  日誌平臺

公司現狀：

1）     公司目前對於項目調試的困難，致使對日誌平臺的需求。

2）     公司的業務暫時還不須要基於日誌的分析需求，對於大容量日誌的記錄及基於日誌的堆棧調用鏈記錄需求。

採用方案：

暫時經過監控平臺的錯誤日誌和本地的錯誤日誌打印，解決目前對錯誤調試的需求。

監控平臺也支持常規業務日誌的打印，可是此業務日誌的打印不支持大容量的需求。（過多打印會形成自身程序阻塞）

方案弊端：

1）     監控平臺也支持常規業務日誌的打印，可是此業務日誌的打印不支持大容量的需求。（過多打印會形成自身程序阻塞）。

2）     不支持調用鏈的日誌記錄及分析。不支持大容量的日誌記錄，不支持日誌的毫秒級查找，便於問題定位。

將來發展：

1）     日誌平臺將來會自行研發（或者結合第三方開源），相似於目前開源的elk。平臺的定位是大容量日誌的收集，挖掘，分析，排查。

2）     更多的是結合自身的業務，和對將來業務發展的規劃，對於日誌平臺的基礎功能作特定的功能或者統計報表展示。

12）  開放接口平臺（我的開源地址：http://git.oschina.net/chejiangyi/ApiView）

公司現狀：

1）     公司的業務急切須要經過soa/微服務的方式提供接口，供第三方開發人員使用。

2）     Soa業務上下游之間須要維護文檔，便於溝通和調試。

採用方案：

我的開源的appview 開放接口平臺。相似swagger。

方案弊端：

目前開放接口平臺實現很簡單，功能也很是精簡通用。還欠缺一些管理功能，好比版本變動記錄和上下游版本變動通知等。

將來發展：

1）     開放接口平臺會根據公司實際的問題和需求不斷的完善功能，如根據公司的接口約定，自動檢測並提醒不規範的接口。自動記錄版本變動，自動郵件通知下游調用方接口變動，自動化的接口治理等功能。

 

13）  分佈式部署平臺

公司現狀：

1）     公司的雲平臺業務尚在初期，流量遠遠沒有上來，也沒有任何性能問題。

2）     雲平臺的部署尚未考慮到分佈式部署發佈和運維的問題，也沒有秒級全平臺部署，版本管理，版本回滾的需求。

採用方案：

暫時前提先考慮人工多服務器發佈解決。

方案弊端：

人工解決，在真實環境中每每出不少問題，畢竟人是最容易犯錯的。因此公司上軌道後，每每採用全自動部署發佈的問題。

將來發展：

1）     自研一套分佈式部署發佈的平臺，作到版本管理，異常回滾，分佈式部署等問題。（這個實現並不複雜，夠用便可）

14）  開放Api網關

公司現狀：

1)        公司目前採用WCF的方式公開服務，調試和使用都很麻煩。

採用方案：

1）     即將採用http 直接公開soa業務服務的方式解決問題，這種方式粗暴但也很是有效。

2）     後面服務中心開發穩定後，全部業務將會遷移到服務中心，全部業務經過tcp鏈接池訪問，提升通訊效率，從而提高性能和響應時間。

方案弊端：

1）     第三方開發人員想經過第三方api訪問，則每每不支持。

將來發展：

1）     開放api網關，將全部內網的服務api，對能夠經過Http的形式進行轉發訪問，Http網關和服務中心保持高性能通訊。

2）     開放api網關遇到性能問題，則負載均衡便可。

3）     開放api網關將管理對外開放的api受權問題，api訪問頻率控制，api訪問權限控制，api訪問的協議控制（xml或者json等）。

剝離開放api管理的功能和api的具體業務實現。

 

4）  總結

因爲時間的預算有限，以上內容均是對於目前基礎服務各個平臺的定位和架構方向的粗略闡述，也沒有對文字從新校對；

由於將來業務的發展每每是多變的，故而基礎服務的功能和方向也會不斷的微調，可是整體的方向應該不會有所改變。但願粗略的文檔可以讓你們理解公司業務架構上的取捨和將來的演變方向。

 

 

By 車江毅

（備註：歡迎你們一塊兒交流，分享，並指出架構的不足，tks！）

開源QQ羣: .net 開源基礎服務  238543768