根據公司目前的業務情況，進行分散式雲平臺基礎服務建設的架構，現狀，取捨，概述以及展望。 包含資料庫中間件，TCP服務框架，認證中心，服務中心，統一監控，配置中心，消息隊列，任務調度平臺，分散式緩存，文件服務，日誌平臺，開發介面平臺，分散式部署平臺，開發Api網關相關內容。 ...
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
