应用的无状态化
很多网站一开始可能不是微服务化的，在早期的一些项目里，我们为了快速上线交付，会做一些单体的应用。随着订单量的发展，我们就开始做所谓的“微服务化”，第一步是把所谓的单体应用，变成应用的无状态化，以登录 SSO 来看，就是一种解决去状态化的方法。 我们会拿到一个 Token，每次访问都会带着 Token，这就是所谓的去状态化。之后每一个应用都有横向可扩的能力。当访问量大的时候，就可以通过加服务器来增强水平扩展的能力。
单体应用的拆分
在做了应用的无状态之后，就是对单体应用的拆分。拆分有几个维度：
- 一个是从系统的维度，最简单的拆法，就是前后台拆开，比如购物车、商品、搜索、首页等属于前端，而后端给网站运营人员用。
- 还可以按功能的维度来拆分，对于用户服务，从 Service 层到表结构，其实是可以独立部署的，这就是微服务的概念。技术架构反应的，就是组织架构，在这种架构下，开发团队分为用户服务开发组、价格开发组、商品开发组等。
- 还可以根据读写维度进行拆分。比如搜索和商城的索引，肯定是独立的两个服务。用户注册下单支付，是一个完整的业务流程。这些是由若干个微服务构成。
服务架构搭建
1. 数据的异构
在大型电商系统里面的服务架构搭建的经验和技巧，首先是数据的异构，以订单表为例，一般订单都非常庞大，一般按照 ID 来分表分库。这种分法对于查询用户所有订单时就要去各表捞数据，因此可以按用户维度来异构一张表。对于数据的存储，会分为热数据、冷数据和温数据，分别存在不同的地方。同时也会对数据进行聚合。在一些订单详情页，由于有很多 AJAX 请求，由于请求数太多，也需要做一些请求合并。后台的服务也要做一个合并。
以商品详情页为例，使几个接口的数据缓存合并在 Redis 中，从 Redis 中取得聚合好的数据，称为数据闭环。这是优化网络请求的通常做法。
2. 缓存
缓存在大型电商系统中是常用的优化技巧。浏览器级别的缓存通过响应头进行设置。还会用到 App 客户端的缓存，把 H5/CSS/JS/ 图片打包，提前拉到客户端，在客户端做一个代理服务器，但是不会读取数据，可以提升用户体验。缓存的使用在网络上还有常用的 CDN。进到接入层后，如果使用软负载，也可以使用内存级别的缓存。
3. 消息队列的应用
消息队列的应用，是做服务解耦的好方法。也要考虑消息失败和重试的场景，需要来做一些额外补偿来防止数据丢失。还有一个机制，是数据的校验和补偿。很多的场景能做到的， 是最终一致性。大型的电商系统和金融系统场景，非常不一样，在设计分布式系统时，这是常用的方式。在电商中大多数情况，只要实现最终一致性就可以了。
高可用的架构设计
高可用的架构设计，对于电商来说，其实高可用是最基本的要求。如果在促销时，引来千万级别的用户，宕机会损失很大。
1. 服务的降级、分组和故障的隔离
基于微服务架构的电商系统，高可用的方案有以下几个部分：
- 首先要支持服务的降级。要做降级的开关，通常写在配置中心里面。比如在大促时，先把订单放在缓存时，再进行落库等操作。
- 同时还要有服务分组和故障的隔离。比如秒杀时，对秒杀的应用单独部署服务，当秒杀的应用挂了之后，不会影响其他服务，因为有服务的隔离。
- 同时要有限流机制，很多的框架都有支持。
2. 流量治理
在极限的场景下，对流量的治理要从多层面进行。比如在促销当天，会开启对于爬虫和机器人的流量进行限流。一般会在大促前进行封板，如果出现问题，就进行回滚，比如数据版本的回滚，在设置数据结构的时候，要做支持带数据版本号的回滚。
如果您喜欢此博客或发现它对您有用，则欢迎对此发表评论。 也欢迎您共享此博客，以便更多人可以参与。 如果博客中使用的图像侵犯了您的版权，请与作者联系以将其删除。 谢谢 ！