1 整体架构

1 微服务架构图

服务集群
- 传统的单体架构，业务功能耦合在一起，难以升级维护
- 微服务根据业务功能模块将单体的项目拆分成许多独立的服务，每个服务独立开发和部署、完成一部分业务功能
- 一个大型的互联网项目可能包含成百上千的服务，最终形成一个服务集群
- 一个业务功能往往需要多个服务共同来完成，比如一个请求可能先调用了服务A，然后服务A再调用服务B，服务B再调用服务C…
注册中心
- 注册中心可以记录服务集群中每一个服务的IP、端口等信息
- 当需要调用某个服务时，不需要知道服务的IP等信息，只需要从注册中心获取即可
配置中心
- 每个服务都有自己的配置文件，配置中心用于统一管理服务的配置文件
- 更改服务配置时不需要到具体的服务中去修改，直接改配置中心的配置文件即可，修改后配置中心会通知具体的服务，实现配置的热更新
服务网关
- 用户调用服务时找的是服务网关
- 服务网关用于权限控制（用户身份校验、服务调用合法性校验）、将用户请求路由到具体的服务、路由的过程中可能还包含负载均衡
分布式缓存
- 分布式缓存用于缓解数据库的压力
- 缓存将数据存放在内存中，访问速度比数据库快很多
分布式搜索
- 简单的查询可以走缓存和数据库，但是海量数据的复杂搜索、统计和分析等，需要用到分布式搜索
消息队列
- 消息队列用于实现服务之间的异步通信，可以提高服务的并发性
- 一个业务往往会跨越多个服务，如果一个服务在调用另一个服务时，一直等待另一个服务的完成，那么将严重影响效率
- 使用消息队列后，如果服务A需要调用服务B和C，A只需要给服务B和C发送一条消息，然后就可以结束服务了
分布式日志和系统监控
- 庞大复杂的服务集群需要有效排查错误的手段，因此引入了分布式日志和系统监控组件
- 分布式日志可以记录服务的运行日志，统一地进行日志的管理
- 系统监控组件可以实时监控服务集群中每一个服务节点的运行状态、CPU负载、内存占用等等信息
微服务的部署
- 微服务集群中的服务数量可能达到成百上千个，难以采用手动部署
- 因此我们需要Jenkins对服务进行自动化编译、利用docker打包编译后的服务形成镜像、利用k8s或Rancher实现服务的自动化部署