原文：https://www.cnblogs.com/chejiangyi/p/5220217.html
一. 业务背景
构建具备高可用，高扩展性，高性能，能承载高并发，大流量的分布式电子商务平台，支持用户，订单，采购，物流，配送，财务等多个项目的协作，便于后续运营报表，分析，便于运维及监控。
二. 基础服务架构说明
参考“大型电子商务架构说明”.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