2） 任务调度平台也可称为类似于hadoop之类的大数据处理，实时计算平台，用于批量处理实时的，非实时的一些动态的流式的任务创建，回收，协调。（如类似爬虫之类的采集业务，和算法分析任务等）
9） 分布式缓存（个人开源地址：）
公司现状：
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） 开放接口平台（个人开源地址：）
公司现状：
1） 公司的业务急切需要通过soa/微服务的方式提供接口，供第三方开发人员使用。
2） Soa业务上下游之间需要维护文档，便于沟通和调试。
采用方案：
个人开源的appview 开放接口平台。类似swagger。
方案弊端：
目前开放接口平台实现很简单，功能也非常精简通用。还欠缺一些管理功能，比如版本变更记录和上下游版本变更通知等。
未来发展：
1） 开放接口平台会根据公司实际的问题和需求不断的完善功能，如根据公司的接口约定，自动检测并提醒不规范的接口。自动记录版本变更，自动邮件通知下游调用方接口变更，自动化的接口治理等功能。
13） 分布式部署平台
公司现状：
1） 公司的云平台业务尚在初期，流量远远没有上来，也没有任何性能问题。
2） 云平台的部署还没有考虑到分布式部署发布和运维的问题，也没有秒级全平台部署，版本管理，版本回滚的需求。
采用方案：
暂时前提先考虑人工多服务器发布解决。
方案弊端：
人工解决，在真实环境中往往出很多问题，毕竟人是最容易犯错的。所以公司上轨道后，往往采用全自动部署发布的问题。
未来发展：
1） 自研一套分布式部署发布的平台，做到版本管理，异常回滚，分布式部署等问题。（这个实现并不复杂，够用即可）
14） 开放Api网关
公司现状：
1) 公司目前采用WCF的方式公开服务，调试和使用都很麻烦。
采用方案：
1） 即将采用http 直接公开soa业务服务的方式解决问题，这种方式粗暴但也非常有效。
2） 后面服务中心开发稳定后，所有业务将会迁移到服务中心，所有业务通过tcp连接池访问，提高通信效率，从而提升性能和响应时间。
方案弊端：
1） 第三方开发人员想通过第三方api访问，则往往不支持。
未来发展：
相关文章
精彩导读
热门资讯
关注我们
