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

背景

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

架构演变

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

基础框架

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

分库分表

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

用户视角如图所示

商户视角如图所示

基础服务

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

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

基础服务如图所示

         分布式缓存（暂未开源）

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

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

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

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

         业务消息队列（开源地址: 博文:）

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

         任务调度平台（开源地址: 博文:）