.net 大型分布式电子商务架构说明

.net大型分布式电子商务架构说明

背景

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

 

架构演变

         基础框架剥离 -> 分库分表 -> 基础服务建设 -> 私有云建设 ->分布式操做系统

 

基础框架

         整个公司不管有多少项目，须要沉淀最基础的框架，里面通常包含核心的分库分表规则，统一的数据库操做类库，统一的通信类，统一的日志类，统一的加密算法，统一的基础服务sdk，公用的一些工具类等等。该框架用于定义最基础的公司架构，设计，统一最基础的技术及项目架构规范，拦截及监控最基础的核心调用等。框架命名通常比较简单，如京东，能够定义为jdf；淘宝，能够定义为tbf。

 

分库分表

         分 库分表为最常规的架构拆分方案。通常会从业务角度进行不一样视角的拆分，如用户视角和商户视角。固然前提也须要业务方面或者其余技术力量的支持，不出现或者 解决拆分后跨多个分库或者分表的表查询及查询结果合并问题。分库分表前也经过须要预估容量，预估性能。分库分表也常常会遇到全局id，或者分布式id自增且惟一的问题，这些都要预先在设计和架构层面要充分考虑。

用户视角如图所示

商户视角如图所示

 

基础服务

         基础服务是系统分布式的一个核心。它每每与操做系统基础组件相对应,只不过它是分布式的。如基础服务通常包含分布式存储，分布式缓存，分布式计算，分布式消息，分布式服务，分布式任务调度，分布式监控等。对应于操做系统的磁盘，内存，cpu，跨进行消息，进程，计划任务，系统监控等。

         公司的基础服务暂时包含几块: 分布式缓存,业务消息队列，任务调度，监控平台，服务中心，分布式锁服务，配置中心。

基础服务如图所示

 

         分布式缓存（开源地址:http://git.oschina.net/chejiangyi/XXF.BaseService.DistributedCache ​博文:http://my.oschina.net/chejiangyi/blog/595038）

         目 前主要是解决核心几个页面的缓存问题，好比首页和列表页等，从而解决高频繁下频繁查询数据库的问题。通常来讲缓存的内容越细越好，这样缓存的内容会比较 多，对数据库的性能优化效果天然很佳。可是缓存越细，则关于缓存的清理工做就越细致，很容易代码编写过程当中忘记清理缓存的状况，影响面和用户体验会很糟 糕。

这 种状况可能有两种方式解决，一种是架构上已经达到服务化和模块化层面，每一个模块只处理自身相关的缓存。如用户服务，订单服务，商户服务，商品服务等，仅处 理自身相关的缓存。那么缓存足够细，固然代码处理也能更加细致。另一种是数据库或者其余层面的修改回调，批量清除相关的缓存；由于粒度很粗，可是可能会 出现大量可用缓存被清理，形成部分雪崩效应。

因此咱们常常会认为使用缓存很容易，可是用好缓存须要的是根据业务需求和许可设计缓存结构，尽可能用好缓存，达到理想的性能；又或者咱们只使用少许粗粒度的缓存，定义好缓存失效时间，部分代码清理部分缓存的方式来，这样能保证热点页面的较高性能; 可是这种状况下咱们依然要注意缓存项不能太多，代码规范管理。

同时咱们注意到业务的缓存会有一些特色，有些缓存具有高热点特性，有些缓存具有瞬间热点特性，有些缓存能够丢失，有些缓存尽可能保证不丢失（不然可能形成雪崩效应）。故咱们要根据实际业务不一样，采用不一样的存储介质。好比redis，memcache，ssdb等，应用场景都略微不一样。而作为公司级的缓存中间件，应该适当的屏蔽这些存储特性，最好能够作到无缝配置，同时具有负载均衡，性能监控等等。

 

         业务消息队列（开源地址: http://git.oschina.net/chejiangyi/Dyd.BusinessMQ 博文:http://my.oschina.net/u/2379842/blog/515860）

         主要是解决业务间的高可靠性消息传递，及功能的异步化处理。这种消息队列必须有如下几点：承载高并发，业务消息不容许丢失，业务消息必须能支撑超大量的堆积而稳定，支持消息的回溯。通常公司可能会考虑企业服务总线（esb），可是针对电子商务瞬间高并发和大量消息堆积的需求，可能不太合适，并且esb包含的东西不少，属于重量级的解决方案，更适合通常企业项目，如企业的内部管理系统。固然一些公司可能也会使用activemq，rabbitmq，kafka，metaq，tbnotify等等，具体的会根据使用场景和实际业务需求选择。好比一些内存的消息中间件，不支持持久化，不支持消息堆积，不支持消息回溯，其实不适合当前公司的业务场景，故而放弃或者部分场景使用。

 

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

         主要是解决业务的后端任务挂载，隔离，定时调度，任务出错报警等。将来能够作到父子任务的关联，任务资源的自动分配和协调，任务的故障转移和均衡。那么网络爬虫，报表分析，弹性计算等资源型任务就能够适用了。

 

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

         每一个公司对监控的需求其实都不同，通常会根据业务不一样，根据架构不一样，根据基础服务不一样，会不一样程度的抓取和集成一些性能指标，业务日志，错误日志，耗时性能，流量等等至监控平台。市面上有不少大而全的监控平台，其实也都提供了sdk作二次开发，目的也在于此。

毕 竟业务不一样，服务器环境不一样，架构基础设施不一样，天然关注的性能点和指标参数也都不同，故从长远发展，监控平台对整个分布式系统的稳定性是具有关键性做 用。大型的分布式电子商务系统，监控平台自己就是大量系统性能分析师的分析思路，分析技巧的总结和沉淀。固然中小型的企业，能够直接使用第三方监控工具， 可是性能分析每每是过后的，非及时性的；又或者第三方的监控工具不少，却没有有效的整合在一块儿，真正分析性能的时候却一片茫然。又或者大型项目单个操做涉 及的系统或服务不少，须要拿到分布式的调用堆栈和调用链…. 种种这些都不免须要公司沉淀本身的监控平台。

 

服务中心（暂未开源）

主要是解决多个项目之间的同步调用，项目的公用api下沉，及远程调用服务的负载均衡，性能监控，预警等等。当前其本质上是服务的管理，公开，协调，运维等，知足业务soa的架构设计。特别是将来对业务细化拆分，模块化，同步解耦起关键做用,相似淘宝的HSF。

 

分布式锁（开源地址:http://git.oschina.net/chejiangyi/XXF.BaseService.DistributedLock 博文:http://my.oschina.net/u/2379842/blog/511291）

分布式锁服务的应用即使在大型业务项目中都不该该常用，特别是对性能要求较高的功能，不建议使用或谨慎使用。任何使用分布式锁的功能建议进行codereview和使用论证。理论上分布式锁经常使用于基础设施服务的分布式协调，可是一些业务对一致性要求较高，特别对瞬间并发致使相同业务同时执行的要求特别高，须要采用分布式锁，不然不采用。

 

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

主要是解决多项目之间的配置聚合及统一管理，同时具有配置的及时更新。若集成任务调度服务能够作到配置的负载均衡和配置的故障转移等。为何要解决公司的项目配置？公司项目从页面前端，采购，物流，配送，财务，b2b等 具备多个项目，多个项目各自一样具备多个服务，多个后台任务，这些程序都互相独立，且部分须要负载均衡（将来数量将达到上千个数量）可是又常常须要公用同 一套配置体系。若每一个程序都配置同一个配置信息，那么将来作某个配置信息的迁移或者更新，运维和开发人员根本不知道哪里须要更新。故配置的汇集管理在大型 项目中是很是有必要的。并且基于配置中心也能够实现热切换，自动故障转移，软性负载等分布式的服务管理能力。

 

以 上这些仅仅是目前公司根据业务发展须要使用的一些基础服务，固然不少公司也会根据自身的业务需求使用分布式存储，分布式搜索引擎等，也会根据自身对基础服 务的可靠性要求，稳定性要求选择不一样的开源基础服务框架进行改造，或者直接使用或者二次封装。从架构师的视角，针对业务发展，要谨慎选择，又要谨慎考虑是 否须要重复造轮子。

文中介绍的相关基础服务可加入开源QQ群: .net开源基础服务,238543768 一块儿交流心得。

 

私有云、混合云建设

         不少创业公司初期，特别是电子商务类型的公司，能够会优先考虑第三方云计算平台来搭建整个平台和架构，天然更多的多是基于成本，资源，人手方面考虑。可是当公司发展到必定程度，创建本身的机房多是很是必要的选择。我的认为云计算的服务器（ecs）达到60-100台集群的时候，考虑搭建公司的机房已经很是有必要了，而当机房的物理机器达到20台的时候，可能也须要考虑放弃单纯的kvm，转而使用openstack及配合使用docker，container等容器技术会更加合适。

         公司对私有云的建设主要是偏重于物理机的资源合理利用，及私有云的有效，灵活管理，甚至必要的状况下，修改openstack的源代码，配合前端的流量和压力状况进行扩容和缩容，更加深层次的自动的负载均衡和自动的故障切换等等。

 

分布式操做系统

         分 布式操做系统自己是一种概念思想的，自己未必具体的如何作的执行步骤。我的认为它更偏向于在云计算平台搭建后的资源更加有效整合，及平台在解决业务能力的 稳定性和扩展能力；从架构师的视角看，也许更多的站在更高的层次全局的俯视整个平台架构，一个总体的电子商务的分布式操做系统和解决方案，而非仅仅是云计 算平台。在这个阶段咱们能够尝试修改openstack的源码和基础服务的源码，二者无缝结合起来，作到高流量时候自动的扩容及低流量时的自动缩容，作到资源的动态调配合。

 

（本说明基于当前公司的实际状况的部分架构简要说明，未涉及工做流，搜索引擎，大数据挖掘等其余方面，仅做参考）

by 车江毅