.Net 大型分布式基础服务架构横向演变概述

一. 业务背景

     构建具有高可用，高扩展性，高性能，能承载高并发，大流量的分布式电子商务平台，支持用户，订单，采购，物流，配送，财务等多个项目的协做，便于后续运营报表，分析，便于运维及监控。

二. 基础服务架构说明

参考“大型电子商务架构说明”.doc

（或http://my.oschina.net/chejiangyi/blog/521950）

三. 基础服务架构横向演进架构图

四. 基础服务横向演进架构概述

1. 分布式任务调度平台演进

   （开源地址:http://git.oschina.net/chejiangyi/Dyd.BaseService.TaskManager博文:http://my.oschina.net/u/2379842/blog/484635）

分布式任务调度平台演进方向主要有两个不一样方向：分布式任务资源调度平台和分布式任务流调度平台，这个两个方向最终会造成两个不一样的系统平台。

   1）分布式任务资源调度平台

    所 有操做系统都将安装java/.net任务管理器服务（相似docker的管理节点），每一个任务管理器里面能够动态运行多个资源任务，全部java /.net服务或者任务都将视为基础的资源任务(相似docker的容器概念)。此平台用于整个公司业务基础资源管理（相似docker的管理系统）。能 够实现服务/任务的，负载均衡（网络，cpu，内存，流量），故障转移，是整个弹性基础服务管理平台的基础。

      使用场景：为了实现基础服务的弹性调度和管理。将来全部业务服务或者后台任务都以“任务”的形式存在，遇到高并发，大流量，硬件压力，自动伸缩（自动扩展任务负载均衡到其余节点）来扩展容量和抗负载能力（在分布式弹性基础服务管理平台中配置管理）。

   

   2）分布式任务流调度平台

    用于建立流程式任务，用于多任务之间的协做和运行。（相似建立办公流程同样的多协做形式的任务，并根据任务的执行结果进行流程的流转。也能够入hadoop同样分布式任务运行）

    使用场景：能够以此基础实现相似风控系统（单个订单进来，多个任务进行风险判断的规则引擎，每一个规则都是一个任务），大型的数据统计和抽取（能够实现map reduce之类的），分布式爬虫任务（运行一个流程，建立多个子爬虫任务不断运行）。

2. 分布式配置中心平台演进

   （开源地址: http://git.oschina.net/chejiangyi/Dyd.BaseService.ConfigManager博文:http://my.oschina.net/u/2379842/blog/533604）

分布式配置中心的演进方向主要会集成两块平台：分布式集群高可用管理平台和分布式服务降级保障平台。固然基础的分布式配置中心的功能将会保留，这两个平台的功能前期会集成入配置中心（后期发展到必定复杂度会从配置中心单独剥离出来，可是又依赖基础的配置中心）。

   1）分布式集群高可用管理平台

    这是基于配置中心（也支持轮询回调）的软性负载均衡，故障检测预警，故障转移实现的统一管理和检测平台，与keepalive之类的软件有些相似，会支持数据库，网站，第三方软件等。

   2）分布式服务降级保障平台

    这是基于配置中心的服务、功能降级保障平台，前期会进行降级配置的统一管理和人工手动降级（后期通常会根据服务的cpu，内存，流量，相应时间等情况，自动进行降级，这时能够考虑单独扩展成一个平台）

 

3. 分布式监控平台演进

   （开源地址：http://git.oschina.net/chejiangyi/Dyd.BaseService.Monitor博文:http://my.oschina.net/u/2379842/blog/510655）

分 布式监控平台演进方向主要是这几块的功能扩展：分布式数据库监控平台，分布式缓存监控平台，分布式服务器集群监控预警平台，分布式业务监控平台，分布式日 志监控分析预警平台等。这几块的功能扩展，所有以插件架构形式集成入监控平台。包括之后根据基础服务和平台演进的要求，愈来愈多的监控插件会集成入监控平 台，而非单纯依赖第三方监控（任何一个高要求的大型网站，必须创建自身的监控体系）。

   1）分布式数据库监控平台

    收 集各类dba常规的sqlserver或mysql数据库的信息汇总，用于分析问题语句，及问题语句自动预警，及一些自动化的索引建议，同时提供cpu， 内存，io，sql阻塞等状况的预警。（特别是大量数据库分库分表的状况下，须要集中优化与预警，及sql性能降低的提醒等）

 

   2）分布式缓存监控平台

    可 以是单纯的某种分布式缓存的监控，如redis，memcache，ssdb等。分布式缓存中间件平台会在自身平台中有监控数据，前期不集成到这里。固然 开源社区也会有不少第三方的相关监控，可是若是想实现自身的一些特殊要求，好比统一的多维度预警就难以实现，特殊分析等，前期具体看状况而定，后期一定自 研一套。

 

   3）分布式服务器集群监控平台

    用于linux,windows的集群监控，根据配置支持多种操做系统指标的监控支持。操做系统级别的监控重要性就没必要说了，也有不少第三方的相关监控工具，具体的也要看状况而定，可是涉及到预警这块仍是必须自研。

 

   4）分布式业务监控平台

    用于业务级别的监控，如api,业务sql，一些业务方法调用频率耗时，及相似百度站长工具的一些行为分析（这块作的东西就很深刻了，须要大数据分析）等。

 

   5）分布式日志监控分析预警平台

    用于聚集整个业务线，基础服务平台错误日志分析及分等级预警，关键业务日志打印分析等，这块是监控平台前期必须自研和统一的。

 

4. 分布式消息队列演进

   （开源地址: http://git.oschina.net/chejiangyi/Dyd.BusinessMQ博文:http://my.oschina.net/u/2379842/blog/515860）

分布式消息队列的演进主要是将来知足公司对不一样类型的消息队列类型的稳定性及性能要求等（目前消息队列相对成熟），主要有几方面扩展：

   1） 支持push方式的消息推送。

   2） 插件化剥离底层消息存储的单一依赖，支持多种存储扩展（内存，文件，数据库）等。

   3） 外围接口兼容actviemq，rabbitmq等多种消息存储及形式。

   4） 支持消息的事务化消费（多方业务订阅消费，一方消费失败则全部消费回滚，不然消息消费出错）

   5） 消息的服务化（broker），支持http，thrift协议等，便于跨语言使用。

   6)  弹性消费能力和弹性扩容等支持。

 

5. 分布式缓存平台演进

（开源地址:http://git.oschina.net/chejiangyi/XXF.BaseService.DistributedCache博文:http://my.oschina.net/chejiangyi/blog/595038）  

目前分布式缓存作的很简单，只是简单的一个sdk代理机制。将来分布式缓存平台演进方向主要有如下几点：

   1） 以redis协议为模板，支持多种缓存存储介质。

   2） 支持一致性（环形）等多种hash分片方式。

   3） 强大的监控及管理平台。

   4） 支持缓存的桶迁移，支持缓存的主备（从），故障转移，负载均衡等。

   5） 缓存的服务化（proxy），支持http，thrift协议等，便于跨语言使用。

6)  弹性缓存扩容等支持。

 

6. 分布式服务中心平台演进

   （暂未开源,开源计划中）

分布式服务中心平台要保持轻量级和高性能，将来演进方向应该包含如下几点：

   1）支持多种服务通讯协议（thrift，自定义协议）。

   2）支持tcp和http。

   3）支持服务负载均衡和故障转移。

   4）强大的监控管理平台（耗时，链接数，cpu等性能，调用链，熔断机制，服务文档等）

5）弹性服务抗压支持。

 

7. 分布式web版本发布管理平台

   分布式web版本发布管理平台主要包含如下两块内容：

   1.用于公司项目web的统一版本控制，负载均衡节点统一发布和回滚。

   2.将来公司手机h5页面版本控制和版本管理。

 

8. 分布式数据库管理平台

   分布式数据库管理平台主要包含两块内容：分布式数据库中间件平台，分布式数据库运维平台。

    1）分布式数据库中间件平台    

主要集成数据库中间件功能，如分库分表sharding机制，sql拦截监控，sql耗时分析，优化建议等，相似tddl及mycat，细节再也不赘述。

2）分布式数据库运维平台

分布式数据库集群的监控及运维管理功能，分布式数据库迁移功能，数据库运维工具，脚本及运维日志等。

 

9. 分布式弹性基础服务管理平台

   分布式弹性基础服务管理平台除了包含自身平台外，还包含分布式高并发做战平台。

   1）分布式高并发做战平台

    用于抢购，秒杀时的一个做战平台，该平台将全部基础服务的外围核心监控，服务升降级配置，手工扩容等相关配置项目快捷的，整合一块儿为多级降级方案。

   2）分布式弹性基础服务管理平台

    用于结合分布式任务资源管理平台，分布式监控，分布式消息队列，分布式服务中心，分布式配置中心等全部基础平台的可控制基础服务及业务服务/任务自动弹性伸缩，故障恢复的配置，管理，监控平台。

    使用场景：

    1）某个业务服务忽然间流量超过阀值，经过分布式任务资源管理平台，将服务扩展到1/n台负载均衡服务，当流量低于某个阀值时自动回收服务。

    2）当某个业务的消息量大量堆积，经过分布式任务资源管理平台，增长业务消息消费任务负载均衡，当消息堆积量低于某个阀值时回收任务。

    3）当某个后台任务的忽然死掉，经过分布式任务资源管理平台，在另一台服务器上尝试重启任务。

 

10. 概述总结

    以 上基础服务演变的概述比较粗糙，可是大体可以代表将来演变的核心方向和功能，这也是根据自身平台业务不一样，方向不一样造成的不一样于常规开源解决方案的演变方 向。固然纠结于细节实现的时候，也会比文中所述更加繁琐，功能更多，性能和实现要求更高，更偏向于轻量级和业务适应性。

 

五. 基础服务自主研发战略

   在 网站研发处于前期或者创业未盈利阶段，能够考虑大量使用第三方的开源框架，以布局总体架构，及考虑架构的完整性和扩展性。虽然如此，但凡大型网站或者网站 涉及到高并发，大流量的压力，核心的基础服务的基础设施必须所有或者部分自研。由于这种性能要求极高的网站，必须对各个细节的把控和要求都很严格，对基础 服务的性能，质量要求也极高，采用一些完善的第三方开源框架反而多是种累赘（如redis,leveldb等轻量级的除外）。并且将来基础服务的统一监 控，弹性伸缩，及与云计算的层面的自主伸缩性契合都须要修改部分核心代码实现。若是采用第三方框架，必须对这些代码很是了解后修改，同时还要不断的跟开源 社区版本保持分支一致。通常第三方开源框架每每是集大成的常规解决方案，更加通用化，而咱们业务每每只须要一部分功能的轻量级解决方案足矣，性能更高。

    故而从短时间看基础服务使用第三方能够快速的部署架构，从长期看基础服务将来一定须要改进或者自主研发。并且研发基础服务的技术难度，在后期作弹性基础服务和云计算平台时来讲其实不算什么，反而是更好的技术沉淀和基石。（目前淘宝，京东，美团，蘑菇街，大众点评，当当网，窝窝团，58同城等都采起部分或者所有自研基础服务的方式。）

六. 基础服务开源战略

    公 司的竞争通常在于商业本质的竞争，而非在于技术的竞争。故开源基础服务对于公司来讲，若能造成开源生态圈，则能够促进开源项目稳定性，优化开源代码，根据 反馈不断的提高自身的基础服务产品，吸引相关的高级技术人才维护检验项目，减小项目的开发维护成本，同时提高公司在技术领域的影响力，提高开发人员的成就 感。（目前淘宝，当当网，58同城等都有部分项目开源）

1）开源成长路线：

路 线1:下载开源源码->学习开源项目->成功部署项目（根据开源文档或者QQ群项目管理员协助）->成为QQ群相关项目管理员 ->了解并解决平常开源项目问题->总结并整理开源项目文档并分享给你们或推广->成为git项目的开发者和参与者

路线2:下载开源源码->学习开源项目->成功部署项目（根据开源文档或者QQ群项目管理员协助）->在实际使用中发现bug并提交bug给项目相关管理员

路线3:下载开源源码->学习开源项目->成功部署项目（根据开源文档或者QQ群项目管理员协助）->自行创建开源项目分支->提交分支新功能给项目官方开发人员->官方开发人员根据项目状况合并新功能并发布新版本

 

2）关于开源生态圈的构想

生态闭环：官方开源项目->第三方参与学习->第三方改进并提交新功能或bug->官方合并新功能或bug->官方发布新版本

为何开源? .net 开源生态自己弱,而强大是你与我不断学习，点滴分享,相互协助，共同营造良好的.net生态环境。

开源理念: 开源是一种态度，分享是一种精神，学习仍需坚持，进步仍需努力，.net生态圈因你我更加美好

 

by 车江毅

 (仅根据实际业务所设想的基础服务演变方向，不包含分布式存储，搜索引擎，大数据等，欢迎交流)

  开源QQ群: .net 开源基础服务  238543768