1. 微服务架构缓存:

(1). 架构迁移:

• 单体架构 -> 集群架构 -> SOA架构 -> 微服务架构
• 目的: 业务快速迭代、快速上线、业务聚合、弹性扩容等.

2. 微服务架构特点:

(1). 特点:

• 系统服务可以根据业务独立拆分. a. 根据需求进行聚合,再将业务单独的进行拆分成独立的服务.
• 微服务单一原则: a. 拆分的服务尽量不要把多个业务都混在一起拆分.

(2). 优点:

• 服务拆分更细,服务可以重复使用. a. 并不代表你的服务拆的越小越好. b. 根据业务的发展,从粗到细的过程.
• 可以针对某个服务做性能扩展和优化,不影响其它服务.
• 服务部署容易,业务之间互相影响较小,可以分别对不同服务做部署升级.

(3). 缺点:

• 服务越来越多,不好管理.
• 服务需要不断增加故障监控、故障治愈、故障预警功能: a. 才能从众多服务中了解服务的健康状态. b. 才能对服务做及时的响应. c. 才能保证服务不会长时间的中断.

3. 如何大规模使用服务?

熔断 超时 可扩展 数据库拆分 防止雪崩 功能降级 跨功能性需求 服务隔离 幂等 缓存 可伸缩

4. 架构图:

• 用户从手机端发送请求到nginx,nginx将请求转到网关
• 网关去连接注册中心去获取注册服务
• 通过服务做路由,再转发到某一些后台的服务当中,
• 然后做业务的一些一个流程的转换，那么同时我们后面还有日志的采集，把一些异常日志、正常日志都可以采集出来以后供用户进行查询
• 对数据库的一些操作，针对不同的业务去抽取不同的数据库，来提供不同的服务来使用。
• 还可以对不同的服务做监控，右上角，它可以去采集不同服务的一些日志、还可以用agent的方式，去采集服务的运行情况
• 然后可以把这些日志采集到如Prometheus中，通过Prometheus反馈到Alertmanager,由Alertmanager发出这种预警通知，以邮件、电话、短信方式。告诉不同的业务开发人员。
• 还有一个故障值班系统，可以把不同的预警系统全部接入到故障值班系统中，由值班系统来通知不同业务系统。 一个值守人员，然后由这个值守人员来处理故障。