京东后端架构是我今年在一位京东后端专家老师的内容讲解里面看到的，原内容已经不在了，今天的分享有写的不当的地方可留言指出。
网站主要是使用C/S架构搭建的B2C模式的电子产品销售平台，采用前后端分离技术。
前端页面使用标签语言vue和css对页面进行渲染，例如图片轮播特效，联动导航栏的特效，以及上下或左右布局，而一些随时会发生变动的数据从后端数据库中查询后返回到前端页面进行展示。
后端的开发工作集中在访问控制层、后台服务层和存储技术层。
考虑到日益变化、不断扩展的功能性需求和高可用、高性能的非功能性需求。采用单体式架构开发的大型Web应用，虽然在大型项目开发早期拥有开发和迭代速度快、便于测试和部署等优点。但随着功能性需求的新增和高并发、高性能、高可用等非功能性需求的增加，单体式架构在项目庞大、功能严重耦合、横向扩容严重浪费资源等因素的作用下难以维护。
于是基于Dubbo框架采用微服务架构把一个应用程序拆分成一组微服务来进行开发和实现的架构风格，每个微服务都是一个独立完整的应用程序，可以独立开发、测试和部署，更加适用于大型应用的开发。
开发涉及的相关理论和主要技术为分布式事务消息中间件 RocketMQ 的事务消息、高并发系统中常使用两种限流算法（令牌桶算法、漏桶算法）、SSM（Spring、Spring MVC、My Batis）框架、Dubbo框架。
访问控制层 包括图片验证码和短信验证码，通过Nginx将请求均匀地分发到各个后端服务器上进行处理。
后台服务层采用9个微服务（自定义网关、用户管理、扫码支付、商品管理、购物车管理、促销管理、订单管理、系统管理、商品秒杀）对商城的功能性需求进行实现。
存储技术层 采用MySQL+HBASE数据库和分布式缓存Redis存储数据，听这位老师讲述很多重要查询都存在HBASE数据库中，是他们的核心数据库。
图片验证码和短信验证码
短信验证码和图片验证码都是出于系统安全考虑的设计的一种验证功能，防止网络黑客模仿用户进行登录，虽然这还是属于防护的底层，但是这种底层级别的防护又是必不可少的，是不可或缺的，因此在用户注册和登录时必须使用这两个技术短信验证码在实现上，主要用户在注册或者登录时，点击发送短信按钮，就会向用户手机发送一条短信，在指定的有效时间内用户必须将受到的验证码填写到相应的输入框中，这样一套流程下来，就能保证是用户本人进行的操作，从而保证后续交易的安全和可靠。要想实现短信验证码这个功能，因为其中涉及到给用户发送手机短信，所以我们必须借用有此功能的第三方平台实现这一步操作，降低了盗号风险。比如云通讯平台。
页面静态化技术
页面静态化后，用户请求的页面就是已经生成好的页面，是向单独的一台存放静态页面的服务器发送请求，这个存放静态页面的服务器不需要请求数据库，不需要将页面和数据进行拼接，而是一个已经生成好的页面，所以也降低了同一个时刻数据库的高并发。为了保证页面的实时性，后端服务器会定时向静态服务器发送更新后的页面，以此保证用户看到的页面的实时有效。
Dubbo微服务框架
选用了Dubbo微服务框架进行项目的整体搭建，Dubbo 微服务框架采用的是RPC远程过程调用的方式完成服务之间的通信，RPC 实现了让分布式或者微服务架构的系统中不同服务之间的相互访问和调用像本地调用一样简单。
Apache Dubbo一款高性能、基于Java语言开发的开源微服务框架，能和Spring 框架无缝集成，提供了RPC通信、服务注册与发现、服务监控和治理等重要功能，并且还支持相当丰富的负载均衡策略，所以，Dubbo的这些特性将加快项目的开发效率，提升项目的整体性能。SpringMVC 提供了拦截器 HandlerInterceptor 用于对请求进行拦截，对请求对象和响应对象进行检查和修改从而实现对请求的拦截和处理。
RocketMQ消息队列
各个微服务访问的数据库是不同的，这就导致了每个微服务仅可以与本服务可访问的数据库之间建立连接，无法和其他微服务可访问的数据库之间建立连接。所以微服务架构应用对事务的控制不可以再选用传统事务的控制方式，
于是分布式事务由此产生。RocketMQ 支持发送多种消息类型，按照发送的消息的功能可以分为普通消息、顺序消息、延时消息、批量消息、过滤消息、事务消息，在项目中基于延时消息进行了订单超时自动取消功能的设计和实现，基于事务消息处理了商品秒杀下单过程中的分布式事务。
MySql和 HBASE数据库
系统中同时使用了 MySQL 和HBASE数据库，MySQL是他们的配置库中心，这两个数据库最大的不同之处就是他们一个是关系型数据库，一个是非关系型数据库。关系型数据库最主要的是特点就是表和表之间通过外键来产生联系，一些表通过外键关联起来从而构建出一个实体模型，然后由这些小的实体来构建出一个大的系统。
而非关系型数据库中就没有表的概念，主要就是通过键值对来对数据进行存储，同时也因为它的数据之间无关系性，在存取时候的效率显然会大大优于关系型数据库。
MySOL数据库在数据量大的时候，明显在查询效率上会有些迟钝，所以我们可以采取一些措施来对查询进行优化，比如对某些频繁要查询的字段建立索引（B+树），或者根据sql语句的执行特点，在写查询语句时候，将一个大的查询分割成一些小的查询语句。
分布式缓存Redis
Redis 拥有丰富的数据类型和相较于关系型数据库超快的数据响应速度，所以在大规模网站和应用的开发过程中，通常使用 Redis 作缓存，存储热点数据，提升系统的响应速度、减轻数据库的压力。Redission 实现的分布式锁中设置了一个watchdog机制，使用了Redission基于 Redis实现的这个分布式锁处理了商品秒杀下单扣减库存时可能会出现的商品超卖问题。
限流
系统的日PV（Pageview：页面浏览量）在千万级以上，为高并发系统，在开发高并发系统时有三把利器用来保护系统：缓存、降级、 限流。其中限流不是用来提高系统的并发量的，也不是提升系统的并发处理能力的，而是保护系统，提高系统的可用性，顾名思义，限流就是限制请求的流量，选择性的处理一部分系统可以处理的流量，处理不了的流量简单处理或不进行处理，常见的限流算法有令牌桶算法和漏桶算法。商品秒杀下单是一个高并发情景，需要基于合适的限流算法和业务流程特点进行设计与实现。
系统功能模块
如自定义网关、用户管理、使用微信支付订单和使用支付宝支付订单等的功能需求，这里不再赘述。
核心类设计-订单管理微服务设计与实现
Pipline 设计模式的使用
由于创建订单流程需要操作多张数据库表，涉及到一连串繁琐的操作，把完成所有操作需要执行的代码都书写到一个类的某个方法中，将会使该方法中的代码行数特别多，且如果代码执行过程中如果出现运行时错误，错误也不好排查。 Pipeline 设计模式又称为流水线设计模式，如果某个任务的处理步骤比较冗长，需要先后由数个不同的阶段分别处理来最终完成，每个阶段的处理结果与下一阶段的处理结果相互联系不可分割，这时候就适合使用 Pipeline 设计模式进行处理。
Pipeline 设计模式完成创建订单流程，其中 OrderProcessPipeline 是负责管理创建订单过程处理逻辑的总线，在OrderProcessPipeline 中维护了一 条 链 表，该链表由几个 value 阀门即SubStockHandler、InitOrderHandler、LogisticalHandler、ClearCartItemHandler、SendMessageHandler 顺序连接组成。在创建订单流程中，依次由 SubStockHandler访问商品库存表进行扣减商品库存、InitOrderHandler 访问订单表进行创建订单信息和远程调用促销管理微服务访问优惠券表删除用户下单时选择的优惠券，LogisticalHandler 访问订单物流信息表创建订单的物流信息、ClearCartItemHandler访问 Redis 删除购物车中创建订单时选择的商品、SendMessageHandler 调用RocketMQ 中的消息生产者 DelayOrderCancelProducer 访问 RocketMQ 发送订单超时未支付取消订单的延迟消息。这几个 value阀门依次先后对 CreateOrderContext这个与创建订单相关的上下文对象进行处理，从而完成整个创建订单流程。
通过使用Pipline设计模式，可以将创建订单的一系列冗长的处理步骤拆分为相互独立的多个阶段，每个阶段由一个 value 阀门遵循单一职责原则单独处理，可以提高代码的可扩展性，方便之后做功能的继续扩展，也使得代码逻辑清晰、易于维护。
如果本文能给你提供启发和帮助，还请留下你的一健三连(点赞、转发、评论)，给我一些鼓励，谢谢。
最近做的产品EasyCut已有100+用户体验 wubai-cq.github.io/easycutpro/ （推荐使用电脑chrome浏览器打开体验最佳，软件可下载）
非常适合在职场中需要频繁切换内、外网的朋友使用