Net分布式云平臺基礎服務建設說明概要

1、.Net分布式云平臺基礎服務建設說明概要1)背景建設云平臺的基礎框架，用于支持各類云服務的業(yè)務的構建及發(fā)展。2)基礎服務根據(jù)目前對業(yè)務的理解和發(fā)展方向，總結抽象由以下幾個基礎服務，如圖所示3)概要說明基礎服務的發(fā)展會根據(jù)業(yè)務的發(fā)展，調(diào)整和完善，也會不斷的改進，演變及完善；當然根據(jù)目前公司的現(xiàn)狀和對基礎服務的迫切程度，基礎服務各模塊的定位和發(fā)展預期將如下所述。1)數(shù)據(jù)庫中間件公司現(xiàn)狀：1)對多種類型數(shù)據(jù)庫的支持需求迫切，如同時支持mysql,orcale,sqlserver這些數(shù)據(jù)庫。最多改動少量代碼就可以在多種數(shù)據(jù)庫類型中切換。2)盡量不要讓開發(fā)人員寫sql代碼，因為原有的開發(fā)人員開發(fā)方式是采

2、用linq的方式，大部分開發(fā)的業(yè)務是winform類型的業(yè)務。米用方案：目前采用entityframework,因entityframework本身采用linq方式編程，自身能夠解析linq為sql,且兼容多種數(shù)據(jù)庫類型的查詢。Entityframework在.net中的流行程度較高，代碼開源，版本發(fā)展較快，且擁有大量應用文檔和學習資料，相比較同類型的框架而言，當首選之。方案弊端：Entityframework的采用只是臨時的方案，因為業(yè)務的需要會持續(xù)比較久的時間。1)從高性能的服務來看，linqtosql的過程必然會有性能損失，即便框架做了解析的緩存，但是也無法避免這些問題。一些復雜語句的查

3、詢，linqtosql目前也會由現(xiàn)意外的解析結果， 復雜的語句查詢難以用linq表達。如果不是對linqtosql這種方式較熟練和關注性能的人，一般寫法上也會導致性能問題。2)從數(shù)據(jù)庫的角度看，目前業(yè)務暫時還使用同一個數(shù)據(jù)庫， 未來業(yè)務會采用多個數(shù)據(jù)庫， 多張數(shù)據(jù)表。 這一點entityframework后面會涉及到分庫的支持和分表的支持，顯然即使修改源碼也很頭疼。而且多個數(shù)據(jù)源，多個數(shù)據(jù)庫類型的支持，意味著同一個業(yè)務要涉及到多種數(shù)據(jù)庫下面性能的調(diào)優(yōu)和運維，特別是涉及到版本升級的數(shù)據(jù)遷移，要兼容多種數(shù)據(jù)庫，意味著工作量真心不小。未來方向：采用單一類型的數(shù)據(jù)庫，會有一個支持sql編寫直連數(shù)據(jù)庫,

4、支持分庫分表的分布式數(shù)據(jù)庫，自動管理數(shù)據(jù)庫連接池，自動提供性能分析及預警等的數(shù)據(jù)庫中間件。2）TCP服務框架公司現(xiàn)狀：1）用于采集程序，采集設備和服務器的直連，發(fā)送采集信息。2）服務器端反向通知連接程序或設備，即時通知信息。3）與工作站的通信環(huán)境（云平臺采用ActiveMQ），連接第三方設備（采用）。米用方案：暫時保持與工作站的通信環(huán)境（云平臺采用ActiveMQ），連接第三方設備（采用signalr集成入）這種方案。因為公司目前采用C#編程，這兩塊技術選型都有相應的C#客戶端或者C#的解決方案的一些示例；故使用起來問題應該不大，但是遇到的問題也不會少。若遇到性能問題，可以簡單的通過擴展多個A

5、ctiveMQ和應用服務的負載均衡來解決其他方案：采用redis或者rabbitmq之類的類似解決方案， 個人傾向與redis的發(fā)布訂閱機制解決，性能不算差（聽聞過上規(guī)模的使用案例及跨語言客戶端sdk）（且可以統(tǒng)一緩存的使用框架，便于維護。）方案弊端：1）無論采用redis,activemq,rabbitmq之類的哪種消息隊列方式解決，都無法避免本質的性能問題，因為這些框架本身是用來解決消息隊列的，因為其內(nèi)存消息轉發(fā)機制，故而用于一些即時通訊，常用于解決內(nèi)網(wǎng)環(huán)境的一些應用交互。目前的場景會應用到廣域網(wǎng)環(huán)境與工作站進行通信，業(yè)內(nèi)類似的解決方案也曾有人使用過，但是也會經(jīng)常由現(xiàn)activemq內(nèi)存滿

6、或者莫名死掉的情況。2）采用signalr應用桂載到上面的使用方式，經(jīng)過一些第三者開發(fā)的經(jīng)驗，也會由現(xiàn)稍微高并發(fā)就由現(xiàn)性能問題或者死掉的情況。Signalr常用于.net技術，也有簡單的使用案列，但是還沒有成熟的上規(guī)模的使用案例和場景。未來方向：采用java的NIO思想或者Windows完成端口思想，搭建純粹的TCPsocket服務是解決本質的一個方案,一般一臺服務器能夠承載10萬的連接，幾千的活動連接（具體看服務器配置等情況)不會有問題(而舊方案可能承載幾千，上百的活動連接就會由現(xiàn)性能問題)。3）認證中心公司現(xiàn)狀：1)原有工作站內(nèi)網(wǎng)子系統(tǒng)的登陸驗證，外網(wǎng)設備登錄驗證，云平臺用戶登錄驗證。2)

7、云平臺用戶菜單權限獲取，操作權限獲取。米用方案：自行研發(fā)公司特有業(yè)務的認證中心平臺，目前僅第一個版本。包含1)設備管理，子系統(tǒng)管理，云平臺用戶管理和權限管理等2)第三方使用的登錄接口，用戶菜單權限接口，用戶操作權限接口。以上功能目前能夠滿足現(xiàn)有公司的業(yè)務。方案弊端：1)目前比較簡單，通過token授權，無名加密，無appid和serect秘鑰授權之類的。故而沒有較強的安全機制，但是能夠滿足實際開發(fā)。而且目前的公司業(yè)務對于安全的要求并不圖O2)通信性能不高， 因為目前采用Http協(xié)議進行通信,本身通信性能不高。而且認證中心將承載所有業(yè)務的認證，基本上所有云項目模塊等業(yè)務都會將請求匯聚到認證中心的

8、接口上，在后續(xù)公司流量的發(fā)展上必然會由現(xiàn)第一個由現(xiàn)接口上的性能問題。未來方向：1)平臺所有的接口實現(xiàn)內(nèi)部必須有redis緩存，平臺接口客戶端使用要有sdk封裝(在sdk內(nèi)部做客戶端緩存，哪怕默認5s的緩存)2)平臺的所有接口后續(xù)接到“高性能服務中心，走TCP連接池的通信方式實現(xiàn)，提高內(nèi)部通信的性能。4)服務中心(個人開源地址：http:/ 作為服務框架必然是走TCP的內(nèi)部通信，性能才會有明顯提升。3)服務治理，協(xié)調(diào)方面的問題為考慮，如沒有考慮調(diào)用鏈死循環(huán)，調(diào)用鏈上的性能導致雪崩，上下游服務監(jiān)控，上下游客戶端服務變更歷史記錄及通知，上下游客戶端服務協(xié)議耦合剝離，服務化層面的負載均衡和故障轉移等等眾多問題。未來方向：1)自研服務中心，將性能，服務治理，協(xié)調(diào)等工作從業(yè)務開發(fā)中抽離抽象由來，業(yè)務開發(fā)只需要關注無狀態(tài)的業(yè)務服務開發(fā)即可。2)所有內(nèi)部的業(yè)務全部剝離(不僅僅是耦合的業(yè)務)，遷移到內(nèi)部的服務中心，如果內(nèi)部服務需要對第三方公開，可以提供Http的開放網(wǎng)關服務進行調(diào)用， 網(wǎng)關層會做一些授權管理等工作， 網(wǎng)關自身做負載均衡。http:/ 以上內(nèi)容均是對于目前基礎服務各個平臺的定位和架構方向的粗略闡述，也沒有對文字重新校對;因為未來業(yè)務