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
