非常完整的电商架构

一、系统架构

1、系统架构

非常完整的系统架构图如下

1.1 网关

网关可以帮助我们完成用户请求的入口，路由。完成统一授权，日志的记录，权限认证和限流及熔断操作。

1.2 注册中心

注册中心实现服务地址管理的功能，解决服务动态感知(上线，下线)。常用的配置中心有：Eureka，Nacos，zookeeper，Consul，redis。

1.3 配置中心

在微服务架构中我们有很多个服务，而每个服务中都会有单独的配置文件的。里面有很多的配置信息的有关联的，而且对于后期的更新维护也会非常的不方便，这时配置中心就上场了。常用的配置中心有：apollo，Nacos，disconf，zookeeper，Spring Cloud Config。

1.4 RPC框架

在微服务架构中，服务与服务之间要实现接口的调用我们肯定要通过相关的RPC(Remote Procedure Call)框架来实现。

常用的RPC框架有:Dubbo,Google的GRPC，Apache的Thrift，微博的Motan，京东的EasyRPC等。我们通过RPC框架可以取调用服务提供者提供的服务，但有一个前提是我们要能找到这个服务。通常我们的服务部署都是集群多节点的部署，所以在消费者这端就不可能直接写死在代码里面，负载均衡解决了。

1.5 负载均衡

在服务注册中心的介绍中我们可以看到负载均衡的应用。我们可以通过Ribbon来实现客户端的负载均衡，负载均衡的策略可以是：轮询，随机，根据响应时间来计算权重的轮询等。

1.6 限流、降级、缓存

在现实的微服务架构中的性能是很难满足所有的用户请求，这时我们就可以通过一些措施来保证我们的核心服务的正常运转。

限流：sentinel（Alibaba）、hystrix（Netflix）

降级：主动降级(订单评论、广告关闭)、被动降级

缓存：降低数据源访问频率、Redis等

容错机制：服务出现挂机，宕机之后的处理机制。

1.7 Bus

Bus消息总线，实现异步化的通信机制。

1.8 链路监控

因为微服务中的服务实在是太多了，为了能更好的监控个服务的情况，肯定就需要链路监控服务，我们可以通过sleuth（Alibaba）+zipkin来实现，应用层监控，系统级监控。

2、项目架构

非常完整的项目架构如下

3、业务架构

非常完整的项目业务组成如下

二、系统设计原则

1、技术设计原则

1.1 无状态原则

单次请求的处理，不依赖于其他的请求。服务器不保存请求状态的服务，就是无状态。无状态的服务器可以无限扩展。

例如，涉及鉴权的请求都是有状态？
token（以下2种情况都使用）：
1。 不存token。坏处：不好控制。token可以自过期（jwt）。
2。存token。坏处：存储负担。

1.2 拆分原则

高内聚，低耦合

1.2.1 系统维度

需与产品研讨制定，商品系统，购物车系统，支付系统，优惠券系统。

1.2.2 功能维度

可以拆分更细，优惠券系统：后台创建券的系统，用户领券系统，用券系统。

1.2.3 读写维度

• 读服务（多级缓存）
• 写服务（分区、分库分表）

这里到读写与数据库或者缓存的读写分离不同。这里的读服务可设计成多级缓存+数据库，而读写分离只指在数据库或者缓存级别。

1.3 服务化原则

节点集群：

• 服务治理：自动注册与发现
• 流量不可控：限流、熔断、降级、隔离、恢复

2、业务设计原则

1.1 防重原则

部分写可以不防重，比如逻辑删除

1.2 模块复用原则

沉淀通用功能

1.3 可追溯原则

任何问题，要有据可查，要好定位

1.4 备份原则

1.4.1 代码备份

1.4.2 数据备份

1.4.3 人员备份

定期review，提交之前有责任人。gerrit + 1

1.5 反馈原则

给调用方一个明确的反馈

A：用户名不存在，账号密码错误，用户无权限。

B：登录错误，请重试。

三、系统衡量指标

1、软件质量衡量标准

1.1 功能性

满足功能要求

1.2 兼容性

1.3 可靠性

容错，可恢复

1.4 可维护性

1.5 可移植性

1.6 安全性

2、系统衡量指标

1.1 吞吐量

单位时间内，能接受和发出的数据量。业务、配置。

TPS: Transaction Per Second

QPS：Queries Per Second

1.2 并发数

1.3 响应时间

串联，并联