1）背景 建設(shè)云平臺(tái)的基礎(chǔ)框架，用于支持各類云服務(wù)的業(yè)務(wù)的構(gòu)建及發(fā)展。 2）基礎(chǔ)服務(wù) 根據(jù)目前對(duì)業(yè)務(wù)的理解和發(fā)展方向，總結(jié)抽象出以下幾個(gè)基礎(chǔ)服務(wù)，如圖所示
3）概要說明 基礎(chǔ)服務(wù)的發(fā)展會(huì)根據(jù)業(yè)務(wù)的發(fā)展，調(diào)整和完善，也會(huì)不斷的改進(jìn)，演變及完善；當(dāng)然根據(jù)目前公司的現(xiàn)狀和對(duì)基礎(chǔ)服務(wù)的迫切程度，基礎(chǔ)服務(wù)各模塊的定位和發(fā)展預(yù)期將如下所述。 1）數(shù)據(jù)庫中間件 公司現(xiàn)狀： 1）對(duì)多種類型數(shù)據(jù)庫的支持需求迫切，如同時(shí)支持mysql，orcale，sqlserver這些數(shù)據(jù)庫。最多改動(dòng)少量代碼就可以在多種數(shù)據(jù)庫類型中切換。 2）盡量不要讓開發(fā)人員寫sql代碼，因?yàn)樵械拈_發(fā)人員開發(fā)方式是采用linq的方式，大部分開發(fā)的業(yè)務(wù)是winform類型的業(yè)務(wù)。 采用方案： 目前采用entity framework，因entity framework 本身采用linq方式編程，自身能夠解析linq為sql，且兼容多種數(shù)據(jù)庫類型的查詢。Entity framework 在.net 中的流行程度較高，代碼開源，版本發(fā)展較快，且擁有大量應(yīng)用文檔和學(xué)習(xí)資料，相比較同類型的框架而言，當(dāng)首選之。 方案弊端： Entity framework 的采用只是臨時(shí)的方案，因?yàn)闃I(yè)務(wù)的需要會(huì)持續(xù)比較久的時(shí)間。 1）從高性能的服務(wù)來看，linq to sql的過程必然會(huì)有性能損失，即便框架做了解析的緩存，但是也無法避免這些問題。一些復(fù)雜語句的查詢，linq to sql 目前也會(huì)出現(xiàn)意外的解析結(jié)果，復(fù)雜的語句查詢難以用linq表達(dá)。如果不是對(duì)linq to sql 這種方式較熟練和關(guān)注性能的人，一般寫法上也會(huì)導(dǎo)致性能問題。 2）從數(shù)據(jù)庫的角度看，目前業(yè)務(wù)暫時(shí)還使用同一個(gè)數(shù)據(jù)庫，未來業(yè)務(wù)會(huì)采用多個(gè)數(shù)據(jù)庫，多張數(shù)據(jù)表。這一點(diǎn)entity framework 后面會(huì)涉及到分庫的支持和分表的支持，顯然即便修改源碼也很頭疼。而且多個(gè)數(shù)據(jù)源，多個(gè)數(shù)據(jù)庫類型的支持，意味著同一個(gè)業(yè)務(wù)要涉及到多種數(shù)據(jù)庫下面性能的調(diào)優(yōu)和運(yùn)維，特別是涉及到版本升級(jí)的數(shù)據(jù)遷移，要兼容多種數(shù)據(jù)庫，意味著工作量真心不小。 未來方向： 采用單一類型的數(shù)據(jù)庫，會(huì)有一個(gè)支持sql編寫直連數(shù)據(jù)庫，支持分庫分表的分布式數(shù)據(jù)庫，自動(dòng)管理數(shù)據(jù)庫連接池，自動(dòng)提供性能分析及預(yù)警等的數(shù)據(jù)庫中間件。
2）TCP服務(wù)框架 公司現(xiàn)狀： 1）用于采集程序，采集設(shè)備和服務(wù)器的直連，發(fā)送采集信息。 2） 服務(wù)器端反向通知連接程序或設(shè)備，即時(shí)通知信息。 3）與工作站的通信環(huán)境（云平臺(tái)采用ActiveMQ）,連接第三方設(shè)備（采用signalr asp.net）。 采用方案： 暫時(shí)保持與工作站的通信環(huán)境（云平臺(tái)采用ActiveMQ）,連接第三方設(shè)備（采用signalr集成入asp.net）這種方案。因?yàn)楣灸壳安捎肅#編程，這兩塊技術(shù)選型都有相應(yīng)的C#客戶端或者C#的解決方案的一些示例；故使用起來問題應(yīng)該不大，但是遇到的問題也不會(huì)少。若遇到性能問題，可以簡(jiǎn)單的通過擴(kuò)展多個(gè)ActiveMQ和應(yīng)用服務(wù)的負(fù)載均衡來解決。 其他方案： 采用redis或者rabbitmq之類的類似解決方案，個(gè)人傾向與redis 的發(fā)布訂閱機(jī)制解決，性能不算差（聽聞過上規(guī)模的使用案例及跨語言客戶端sdk）（且可以統(tǒng)一緩存的使用框架，便于維護(hù)。） 方案弊端： 1）無論采用redis，activemq，rabbitmq之類的哪種消息隊(duì)列方式解決，都無法避免本質(zhì)的性能問題，因?yàn)檫@些框架本身是用來解決消息隊(duì)列的，因?yàn)槠鋬?nèi)存消息轉(zhuǎn)發(fā)機(jī)制，故而用于一些即時(shí)通訊，常用于解決內(nèi)網(wǎng)環(huán)境的一些應(yīng)用交互。目前的場(chǎng)景會(huì)應(yīng)用到廣域網(wǎng)環(huán)境與工作站進(jìn)行通信，業(yè)內(nèi)類似的解決方案也曾有人使用過，但是也會(huì)經(jīng)常出現(xiàn)activemq 內(nèi)存滿或者莫名死掉的情況。 2）采用signalr 應(yīng)用掛載到asp.net 上面的使用方式，經(jīng)過一些第三者開發(fā)的經(jīng)驗(yàn)，也會(huì)出現(xiàn)稍微高并發(fā)就出現(xiàn)性能問題或者死掉的情況。Signalr 常用于.net 技術(shù)，也有簡(jiǎn)單的使用案列，但是還沒有成熟的上規(guī)模的使用案例和場(chǎng)景。 未來方向： 采用java的NIO思想或者Windows 完成端口思想,搭建純粹的TCP socket服務(wù)是解決本質(zhì)的一個(gè)方案，一般一臺(tái)服務(wù)器能夠承載10萬的連接，幾千的活動(dòng)連接（具體看服務(wù)器配置等情況）不會(huì)有問題（而舊方案可能承載幾千，上百的活動(dòng)連接就會(huì)出現(xiàn)性能問題）。
3）認(rèn)證中心 公司現(xiàn)狀： 1） 原有工作站內(nèi)網(wǎng)子系統(tǒng)的登陸驗(yàn)證，外網(wǎng)設(shè)備登錄驗(yàn)證，云平臺(tái)用戶登錄驗(yàn)證。 2） 云平臺(tái)用戶菜單權(quán)限獲取，操作權(quán)限獲取。 采用方案： 自行研發(fā)公司特有業(yè)務(wù)的認(rèn)證中心平臺(tái)，目前僅第一個(gè)版本。包含 1）設(shè)備管理，子系統(tǒng)管理，云平臺(tái)用戶管理和權(quán)限管理等 2）第三方使用的登錄接口，用戶菜單權(quán)限接口，用戶操作權(quán)限接口。 以上功能目前能夠滿足現(xiàn)有公司的業(yè)務(wù)。 方案弊端： 1）目前比較簡(jiǎn)單，通過token授權(quán)，無名加密，無appid和serect秘鑰授權(quán)之類的。故而沒有較強(qiáng)的安全機(jī)制，但是能夠滿足實(shí)際開發(fā)。而且目前的公司業(yè)務(wù)對(duì)于安全的要求并不高。 2）通信性能不高，因?yàn)槟壳安捎肏ttp協(xié)議進(jìn)行通信，本身通信性能不高。而且認(rèn)證中心將承載所有業(yè)務(wù)的認(rèn)證，基本上所有云項(xiàng)目模塊等業(yè)務(wù)都會(huì)將請(qǐng)求匯聚到認(rèn)證中心的接口上，在后續(xù)公司流量的發(fā)展上必然會(huì)出現(xiàn)第一個(gè)出現(xiàn)接口上的性能問題。 未來方向： 1） 平臺(tái)所有的接口實(shí)現(xiàn)內(nèi)部必須有redis緩存，平臺(tái)接口客戶端使用要有sdk封裝（在sdk內(nèi)部做客戶端緩存，哪怕默認(rèn)5 s的緩存） 2） 平臺(tái)的所有接口后續(xù)接到“高性能服務(wù)中心”，走TCP連接池的通信方式實(shí)現(xiàn)，提高內(nèi)部通信的性能。 4） 服務(wù)中心（個(gè)人開源地址：http://git.oschina.net/chejiangyi/Dyd.BaseService.ServiceCenter） 公司現(xiàn)狀： 1） 項(xiàng)目之間出現(xiàn)互相調(diào)用的業(yè)務(wù)耦合，目前采用dll的方式調(diào)用，但是出現(xiàn)dll更新出錯(cuò)及管理等情況，導(dǎo)致開發(fā)人員認(rèn)為效率不高。 2） 公司迫切希望采用微服務(wù)/soa的架構(gòu)方式來剝離項(xiàng)目的業(yè)務(wù)耦合，簡(jiǎn)化上下游業(yè)務(wù)調(diào)用的管理方式。 采用方案： 1） 暫時(shí)采用Http restful類似的方式提供服務(wù)化的接口，供第三方接口調(diào)用，同時(shí)這也符合soa服務(wù)化的架構(gòu)思想。 2） 通過api view 自動(dòng)公開接口文檔，上下游之間調(diào)用調(diào)試，方便開發(fā)人員溝通協(xié)調(diào)。 方案弊端： 1） 個(gè)人經(jīng)驗(yàn)：服務(wù)化的接口方式有效的,對(duì)業(yè)務(wù)溝通也是非常有幫助的，但是未必能夠真正的在效率上得到本質(zhì)的提升。但是對(duì)于項(xiàng)目的模塊化管理應(yīng)該有較好的幫助。 2） Http的接口通信方式效率并不高，作為服務(wù)框架必然是走TCP的內(nèi)部通信，性能才會(huì)有明顯提升。 3） 服務(wù)治理，協(xié)調(diào)方面的問題為考慮，如沒有考慮調(diào)用鏈死循環(huán)，調(diào)用鏈上的性能導(dǎo)致雪崩，上下游服務(wù)監(jiān)控，上下游客戶端服務(wù)變更歷史記錄及通知，上下游客戶端服務(wù)協(xié)議耦合剝離，服務(wù)化層面的負(fù)載均衡和故障轉(zhuǎn)移等等眾多問題。 未來方向： 1） 自研服務(wù)中心，將性能，服務(wù)治理，協(xié)調(diào)等工作從業(yè)務(wù)開發(fā)中抽離抽象出來，業(yè)務(wù)開發(fā)只需要關(guān)注無狀態(tài)的業(yè)務(wù)服務(wù)開發(fā)即可。 2） 所有內(nèi)部的業(yè)務(wù)全部剝離（不僅僅是耦合的業(yè)務(wù)），遷移到內(nèi)部的服務(wù)中心，如果內(nèi)部服務(wù)需要對(duì)第三方公開，可以提供Http的開放網(wǎng)關(guān)服務(wù)進(jìn)行調(diào)用，網(wǎng)關(guān)層會(huì)做一些授權(quán)管理等工作，網(wǎng)關(guān)自身做負(fù)載均衡。 5） 統(tǒng)一監(jiān)控（個(gè)人開源地址：http://git.oschina.net/chejiangyi/Dyd.BaseService.Monitor） 公司現(xiàn)狀： 1）項(xiàng)目處于前期研發(fā)階段，沒有較大規(guī)模的服務(wù)器集群，沒有遇到多版本接口兼容，沒有遇到線上監(jiān)控問題和線上排查問題，性能問題的痛苦，對(duì)這些情況還不了解和敏感。 2）開發(fā)人員希望解決項(xiàng)目開發(fā)調(diào)試時(shí)候，錯(cuò)誤日志及錯(cuò)誤日志的堆棧問題，調(diào)用路徑問題排查。 采用方案： 1） 采用Http Restful 服務(wù)化業(yè)務(wù)接口的方式，應(yīng)該能緩解項(xiàng)目開發(fā)調(diào)試的問題。（開發(fā)調(diào)試問題以前沒遇到過，應(yīng)該跟原來架構(gòu)和技術(shù)采用wcf等方式有關(guān)導(dǎo)致） 2） 搭建分布式監(jiān)控平臺(tái)，因?yàn)槭潜救艘延虚_源的項(xiàng)目，使用起來問題不大。能夠解決很多云上服務(wù)器管理，性能監(jiān)控及預(yù)警，sql性能監(jiān)控，api接口性能監(jiān)控，統(tǒng)一錯(cuò)誤日志等。 方案弊端： 1） 個(gè)人還不是特別確切了解目前項(xiàng)目開發(fā)人員調(diào)試項(xiàng)目開發(fā)過程中，對(duì)日志問題真正迫切的本質(zhì)原因，也沒深刻體驗(yàn)（一直開發(fā)以來沒有遇到問題難調(diào)試的問題，可能現(xiàn)有公司項(xiàng)目架構(gòu)方式關(guān)系密切），所以不知道是否能夠解決。 2） 目前分布式監(jiān)控平臺(tái)是在原有公司開發(fā)的簡(jiǎn)化版本，為了實(shí)現(xiàn)整體項(xiàng)目架構(gòu)的監(jiān)控那塊的抽象和布局而研發(fā)的。性能和功能上還有很多的優(yōu)化和改進(jìn)空間。（當(dāng)然支持公司的現(xiàn)狀還是綽綽有余） 未來方向： 1） 根據(jù)公司的業(yè)務(wù)對(duì)監(jiān)控的需求，還需要不斷的改進(jìn)和完善監(jiān)控平臺(tái)。 2） 監(jiān)控平臺(tái)的功能和性能需要完善，底層將使用nosql來存儲(chǔ)實(shí)現(xiàn)。 6） 配置中心（個(gè)人開源地址：http://git.oschina.net/chejiangyi/Dyd.BaseService.ConfigManager） 公司現(xiàn)狀： 1） 目前公司有類似配置中心的功能，用于基本的業(yè)務(wù)配置的使用，比較簡(jiǎn)單。 2） 云這塊業(yè)務(wù)尚處于簡(jiǎn)單的業(yè)務(wù)模型和業(yè)務(wù)狀態(tài)，未遇到真正線上復(fù)雜的業(yè)務(wù)和業(yè)務(wù)剝離的需求，及異步化的功能點(diǎn)，統(tǒng)計(jì)類的功能等等，對(duì)分布式配置中心的本質(zhì)需求和問題還沒有真正暴露出來。 采用方案： 依舊使用原有的配置中心功能，同時(shí)分布式的配置中心也會(huì)搭建。原有的配置中心適合業(yè)務(wù)配置的存儲(chǔ)，現(xiàn)有的配置中心可以用于業(yè)務(wù)配置的存儲(chǔ)，也可以用于分布式架構(gòu)的環(huán)境配置協(xié)調(diào)問題。 方案弊端： 會(huì)維持兩套配置中心的運(yùn)維，在業(yè)務(wù)架構(gòu)上比較難以區(qū)別，業(yè)務(wù)上容易混亂。 未來方向： 1） 兩塊配置中心將根據(jù)業(yè)務(wù)的需求和方向，在一定程度上進(jìn)行融合。但就目前的公司精力不會(huì)著重這塊。 2） 配置中心將根據(jù)公司的業(yè)務(wù)發(fā)展，也會(huì)繼續(xù)演變出更多的功能，不過暫時(shí)不明朗。 7） 消息隊(duì)列（個(gè)人開源地址：http://git.oschina.net/chejiangyi/Dyd.BusinessMQ） 公司現(xiàn)狀： 1） 目前公司在云平臺(tái)端與工作站異步通信是通過ActiveMQ進(jìn)行的。 2） 云平臺(tái)項(xiàng)目還處于前期研發(fā)起步階段，業(yè)務(wù)復(fù)雜度還不夠，對(duì)性能的要求不高，也未涉及同一業(yè)務(wù)異步化拆分和解耦。 3） 公司的采集方面的業(yè)務(wù)還未做到真正的大規(guī)模分析，大規(guī)模采集的場(chǎng)景。 采用方案： 出于公司架構(gòu)統(tǒng)一的現(xiàn)狀考慮，暫時(shí)采用ActiveMQ，也方便java，C#等跨語言的異步通信。當(dāng)然也僅僅能應(yīng)用與異步化的簡(jiǎn)單的即時(shí)通信效果。 方案弊端： ActiveMQ 只能作為異步的即時(shí)通信暫時(shí)使用，就目前的性能和穩(wěn)定性來說，并不是長(zhǎng)遠(yuǎn)之計(jì)。 1） 若是為了持久化的Tcp通信，未來自己會(huì)有TCP服務(wù)的搭建來確保。 2） 若是為了消息隊(duì)列的通信，未來更多考慮消息的堆積性能，消息的高穩(wěn)定性和高可靠性（不能丟失消息）。 3） 若是考慮消息隊(duì)列收集消息便于后續(xù)采集分析，未來更多考慮類似kafka的方案。 未來發(fā)展： 消息隊(duì)列有眾多的解決方案，也有眾多的一些特性適用于不同的業(yè)務(wù)場(chǎng)景。針對(duì)這些不同的場(chǎng)景和方案，個(gè)人會(huì)做如下考慮： 1） 自建的一套消息隊(duì)列平臺(tái)，自建的消息隊(duì)列可以剝離底層的存儲(chǔ)引擎，通過不同的存儲(chǔ)引擎的特性，達(dá)到適用不同場(chǎng)景和方案的目的。（如存儲(chǔ)引擎為redis，ssdb，數(shù)據(jù)庫等，即便實(shí)現(xiàn)邏輯相同，但是性能不同，可靠性表現(xiàn)也不同） 2） 自建的一套消息隊(duì)列中間件，可以剝離具體的消息隊(duì)列實(shí)現(xiàn)，抽象出常規(guī)消息隊(duì)列的使用方式。僅通過修改連接字符串或者配置類，就能實(shí)現(xiàn)不同消息平臺(tái)的切換。（如底層消息服務(wù)可能是activemq，rabbitmq，redis，kafka，對(duì)上層業(yè)務(wù)可以是透明，甚至無縫切換） 8） 任務(wù)調(diào)度平臺(tái)（個(gè)人開源地址：http://git.oschina.net/chejiangyi/Dyd.BaseService.TaskManager） 公司現(xiàn)狀： 1） 公司目前業(yè)務(wù)尚處于前期，未有業(yè)務(wù)需求有類似后臺(tái)任務(wù)統(tǒng)計(jì)，后臺(tái)任務(wù)消費(fèi)之類的業(yè)務(wù)需求。 2） 任務(wù)調(diào)度平臺(tái)是所有基礎(chǔ)服務(wù)的一個(gè)基礎(chǔ)環(huán)節(jié)，目前也僅在基礎(chǔ)服務(wù)部署中使用。 采用方案： 個(gè)人開源的分布式任務(wù)調(diào)度平臺(tái)。 方案弊端： 分布式任務(wù)調(diào)度平臺(tái)目前僅屬于一個(gè)簡(jiǎn)單的任務(wù)調(diào)度平臺(tái)，未來的發(fā)展方向還有很大的空間。 未來發(fā)展： 1） 所有公司的業(yè)務(wù)都被視為一個(gè)業(yè)務(wù)任務(wù)，所有的業(yè)務(wù)任務(wù)都將被掛載到任務(wù)調(diào)度平臺(tái)，任務(wù)調(diào)度平臺(tái)會(huì)根據(jù)分布式集群的負(fù)載情況，自動(dòng)分配集群服務(wù)器用于業(yè)務(wù)的負(fù)載均衡和故障轉(zhuǎn)移等資源的調(diào)度和協(xié)調(diào)。（如所有的接口服務(wù)，所有的后臺(tái)任務(wù)，所有的消息消費(fèi)任務(wù)等等） 2） 任務(wù)調(diào)度平臺(tái)也可稱為類似于hadoop之類的大數(shù)據(jù)處理，實(shí)時(shí)計(jì)算平臺(tái)，用于批量處理實(shí)時(shí)的，非實(shí)時(shí)的一些動(dòng)態(tài)的流式的任務(wù)創(chuàng)建，回收，協(xié)調(diào)。（如類似爬蟲之類的采集業(yè)務(wù)，和算法分析任務(wù)等） 9） 分布式緩存（個(gè)人開源地址：http://git.oschina.net/chejiangyi/XXF.BaseService.DistributedCache） 公司現(xiàn)狀： 1） 目前公司的業(yè)務(wù)還不需要用到分布式緩存的使用，除了認(rèn)證中心這塊應(yīng)該在后續(xù)涉及到一些性能問題。 采用方案： 個(gè)人開源的分布式緩存中間件。（目前實(shí)現(xiàn)的是基于memcached協(xié)議的一個(gè)統(tǒng)一的分布式緩存框架） 方案弊端： 僅支持基礎(chǔ)的分布式緩存框架，整體數(shù)據(jù)結(jié)構(gòu)比較簡(jiǎn)單（key+定時(shí)過期失效），但是也是緩存中最實(shí)用的功能。 未來發(fā)展： 1） 支持更多的協(xié)議，如redis的通信協(xié)議。及更多底層存儲(chǔ)框架的抽象。（每種緩存框架都有特定的使用場(chǎng)景和微妙的差別） 2） 分布式緩存的統(tǒng)一性能監(jiān)控；一致性哈希的支持便于實(shí)現(xiàn)定制的故障轉(zhuǎn)移方案，避免雪崩等緩存失效場(chǎng)景。 3） 根據(jù)公司的業(yè)務(wù)支持其他緩存場(chǎng)景，如本地緩存一致性（協(xié)同分布式消息隊(duì)列實(shí)現(xiàn)）的支持。 10） 文件服務(wù) 公司現(xiàn)狀： 1） 公司目前的采集的業(yè)務(wù)將信息都存在本地的應(yīng)用服務(wù)器，以文件形式存儲(chǔ)。 2） 公司的采集業(yè)務(wù)信息文件，需要持久保存。 采用方案： 暫時(shí)保持現(xiàn)狀。 方案弊端： 1） 無論從容量的擴(kuò)容和性能的角度看，單獨(dú)的文件服務(wù)器是一個(gè)長(zhǎng)遠(yuǎn)的必然需求。 2） 目前的業(yè)務(wù)可能涉及到文件的連續(xù)存儲(chǔ)和文件部分內(nèi)容的讀取的需求，就市面上的開源文件服務(wù)可能不滿足需求。 3） 個(gè)人現(xiàn)在對(duì)公司關(guān)于文件服務(wù)的業(yè)務(wù)需求，還不是特別了解。 未來發(fā)展： 1） 考慮自研分布式文件服務(wù)，讀取性能未必勝于市面的開源文件服務(wù)。（自研的文件服務(wù)應(yīng)該還是基于windows文件管理結(jié)構(gòu)），但是靈活度會(huì)更高。 2） 自研的分布式文件服務(wù)sdk，要在使用上抽象，并兼容公司的底層存儲(chǔ)差異（有些大文件存儲(chǔ)可能還是使用第三方存儲(chǔ)，但是對(duì)于開發(fā)來說是透明無感知的）。 11） 日志平臺(tái) 公司現(xiàn)狀： 1） 公司目前對(duì)于項(xiàng)目調(diào)試的困難，導(dǎo)致對(duì)日志平臺(tái)的需求。 2） 公司的業(yè)務(wù)暫時(shí)還不需要基于日志的分析需求，對(duì)于大容量日志的記錄及基于日志的堆棧調(diào)用鏈記錄需求。 采用方案： 暫時(shí)通過監(jiān)控平臺(tái)的錯(cuò)誤日志和本地的錯(cuò)誤日志打印，解決目前對(duì)錯(cuò)誤調(diào)試的需求。 監(jiān)控平臺(tái)也支持常規(guī)業(yè)務(wù)日志的打印，但是此業(yè)務(wù)日志的打印不支持大容量的需求。（過多打印會(huì)造成自身程序阻塞） 方案弊端： 1） 監(jiān)控平臺(tái)也支持常規(guī)業(yè)務(wù)日志的打印，但是此業(yè)務(wù)日志的打印不支持大容量的需求。（過多打印會(huì)造成自身程序阻塞）。 2） 不支持調(diào)用鏈的日志記錄及分析。不支持大容量的日志記錄，不支持日志的毫秒級(jí)查找，便于問題定位。 未來發(fā)展： 1） 日志平臺(tái)未來會(huì)自行研發(fā)（或者結(jié)合第三方開源），類似于目前開源的elk。平臺(tái)的定位是大容量日志的收集，挖掘，分析，排查。 2） 更多的是結(jié)合自身的業(yè)務(wù)，和對(duì)未來業(yè)務(wù)發(fā)展的規(guī)劃，對(duì)于日志平臺(tái)的基礎(chǔ)功能做特定的功能或者統(tǒng)計(jì)報(bào)表展現(xiàn)。 12） 開放接口平臺(tái)（個(gè)人開源地址：http://git.oschina.net/chejiangyi/ApiView） 公司現(xiàn)狀： 1） 公司的業(yè)務(wù)急切需要通過soa/微服務(wù)的方式提供接口，供第三方開發(fā)人員使用。 2） Soa業(yè)務(wù)上下游之間需要維護(hù)文檔，便于溝通和調(diào)試。 采用方案： 個(gè)人開源的appview 開放接口平臺(tái)。類似swagger。 方案弊端： 目前開放接口平臺(tái)實(shí)現(xiàn)很簡(jiǎn)單，功能也非常精簡(jiǎn)通用。還欠缺一些管理功能，比如版本變更記錄和上下游版本變更通知等。 未來發(fā)展： 1） 開放接口平臺(tái)會(huì)根據(jù)公司實(shí)際的問題和需求不斷的完善功能，如根據(jù)公司的接口約定，自動(dòng)檢測(cè)并提醒不規(guī)范的接口。自動(dòng)記錄版本變更，自動(dòng)郵件通知下游調(diào)用方接口變更，自動(dòng)化的接口治理等功能。
13） 分布式部署平臺(tái) 公司現(xiàn)狀： 1） 公司的云平臺(tái)業(yè)務(wù)尚在初期，流量遠(yuǎn)遠(yuǎn)沒有上來，也沒有任何性能問題。 2） 云平臺(tái)的部署還沒有考慮到分布式部署發(fā)布和運(yùn)維的問題，也沒有秒級(jí)全平臺(tái)部署，版本管理，版本回滾的需求。 采用方案： 暫時(shí)前提先考慮人工多服務(wù)器發(fā)布解決。 方案弊端： 人工解決，在真實(shí)環(huán)境中往往出很多問題，畢竟人是最容易犯錯(cuò)的。所以公司上軌道后，往往采用全自動(dòng)部署發(fā)布的問題。 未來發(fā)展： 1） 自研一套分布式部署發(fā)布的平臺(tái)，做到版本管理，異?；貪L，分布式部署等問題。（這個(gè)實(shí)現(xiàn)并不復(fù)雜，夠用即可） 14） 開放Api網(wǎng)關(guān) 公司現(xiàn)狀： 1) 公司目前采用WCF的方式公開服務(wù)，調(diào)試和使用都很麻煩。 采用方案： 1） 即將采用http 直接公開soa業(yè)務(wù)服務(wù)的方式解決問題，這種方式粗暴但也非常有效。 2） 后面服務(wù)中心開發(fā)穩(wěn)定后，所有業(yè)務(wù)將會(huì)遷移到服務(wù)中心，所有業(yè)務(wù)通過tcp連接池訪問，提高通信效率，從而提升性能和響應(yīng)時(shí)間。 方案弊端： 1） 第三方開發(fā)人員想通過第三方api訪問，則往往不支持。 未來發(fā)展： ２） 開放api網(wǎng)關(guān)，將所有內(nèi)網(wǎng)的服務(wù)api，對(duì)可以通過Http的形式進(jìn)行轉(zhuǎn)發(fā)訪問，Http網(wǎng)關(guān)和服務(wù)中心保持高性能通信。 2） 開放api網(wǎng)關(guān)遇到性能問題，則負(fù)載均衡即可。 3） 開放api網(wǎng)關(guān)將管理對(duì)外開放的api授權(quán)問題，api訪問頻率控制，api訪問權(quán)限控制，api訪問的協(xié)議控制（xml或者json等）。 剝離開放api管理的功能和api的具體業(yè)務(wù)實(shí)現(xiàn)。
4） 總結(jié) 由于時(shí)間的預(yù)算有限，以上內(nèi)容均是對(duì)于目前基礎(chǔ)服務(wù)各個(gè)平臺(tái)的定位和架構(gòu)方向的粗略闡述，也沒有對(duì)文字重新校對(duì)； 因?yàn)槲磥順I(yè)務(wù)的發(fā)展往往是多變的，故而基礎(chǔ)服務(wù)的功能和方向也會(huì)不斷的微調(diào)，但是總體的方向應(yīng)該不會(huì)有所改變。希望粗略的文檔能夠讓大家理解公司業(yè)務(wù)架構(gòu)上的取舍和未來的演變方向。
|
|
|
