在国内做网站网站代理,剪映导出的视频字幕有乱码,怎么去优化关键词,外贸单子怎么找1#xff09; 背景 建设云平台的基础框架#xff0c;用于支持各类云服务的业务的构建及发展。 2#xff09; 基础服务 根据目前对业务的理解和发展方向#xff0c;总结抽象出以下几个基础服务#xff0c;如图所示 3#xff09; 概要说明 基础服务的发展会根据业务的发… 1 背景 建设云平台的基础框架用于支持各类云服务的业务的构建及发展。 2 基础服务 根据目前对业务的理解和发展方向总结抽象出以下几个基础服务如图所示 3 概要说明 基础服务的发展会根据业务的发展调整和完善也会不断的改进演变及完善当然根据目前公司的现状和对基础服务的迫切程度基础服务各模块的定位和发展预期将如下所述。 1 数据库中间件 公司现状 1 对多种类型数据库的支持需求迫切如同时支持mysqlorcalesqlserver这些数据库。最多改动少量代码就可以在多种数据库类型中切换。 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 无论采用redisactivemqrabbitmq之类的哪种消息队列方式解决都无法避免本质的性能问题因为这些框架本身是用来解决消息队列的因为其内存消息转发机制故而用于一些即时通讯常用于解决内网环境的一些应用交互。目前的场景会应用到广域网环境与工作站进行通信业内类似的解决方案也曾有人使用过但是也会经常出现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也方便javaC#等跨语言的异步通信。当然也仅仅能应用与异步化的简单的即时通信效果。 方案弊端 ActiveMQ 只能作为异步的即时通信暂时使用就目前的性能和稳定性来说并不是长远之计。 1 若是为了持久化的Tcp通信未来自己会有TCP服务的搭建来确保。 2 若是为了消息队列的通信未来更多考虑消息的堆积性能消息的高稳定性和高可靠性不能丢失消息。 3 若是考虑消息队列收集消息便于后续采集分析未来更多考虑类似kafka的方案。 未来发展 消息队列有众多的解决方案也有众多的一些特性适用于不同的业务场景。针对这些不同的场景和方案个人会做如下考虑 1 自建的一套消息队列平台自建的消息队列可以剥离底层的存储引擎通过不同的存储引擎的特性达到适用不同场景和方案的目的。如存储引擎为redisssdb数据库等即便实现逻辑相同但是性能不同可靠性表现也不同 2 自建的一套消息队列中间件可以剥离具体的消息队列实现抽象出常规消息队列的使用方式。仅通过修改连接字符串或者配置类就能实现不同消息平台的切换。如底层消息服务可能是activemqrabbitmqrediskafka对上层业务可以是透明甚至无缝切换 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 开源是一种态度分享是一种精神学习仍需坚持进步仍需努力.net生态圈因你我更加美好。 原文地址http://www.cnblogs.com/chejiangyi/p/5666250.html .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
