一、系统架构
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 响应时间
串联,并联