文章目录
- 一、 认识微服务
- 二、 微服务演变
- 2.1、 单体架构
- 2.2、 分布式架构
- 2.3、 微服务
- 2.4、 微服务方案对比
- 三、 注册中心
- 3.1、 Eureka
- 3.2、 Nacos
- 3.2.1、服务分级存储模型
- 3.2.2、权重配置
- 3.2.3、环境隔离
一、 认识微服务
二、 微服务演变
随着互联网行业的发展，对服务的要求也越来越高，服务架构也从单体架构逐渐演变为现在流行的微服务架构。
2.1、 单体架构
单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。
优点：
- 架构简单
- 部署成本低
缺点：
- 耦合度高（维护困难、升级困难）
2.2、 分布式架构
分布式架构：根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务。
优点：
- 降低服务耦合
- 有利于服务升级和拓展
缺点：
- 服务调用关系错综复杂
2.3、 微服务
微服务的架构特征：
- 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
- 自治：团队独立、技术独立、数据独立，独立部署和交付
- 面向服务：服务提供统一标准的接口，与语言和技术无关
- 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题
微服务的上述特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合。
因此，可以认为微服务是一种经过良好架构设计的分布式架构方案 。
2.4、 微服务方案对比
但方案该怎么落地？选用什么样的技术栈？全球的互联网公司都在积极尝试自己的微服务落地方案。
其中在Java领域最引人注目的就是SpringCloud提供的方案了。
SpringCloud集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验。
三、 注册中心
3.1、 Eureka
eureka的作用：
消费者该如何获取服务提供者具体信息？
- 服务提供者启动时向eureka注册自己的信息
- eureka保存这些信息
- 消费者根据服务名称向eureka拉取提供者信息（服务发现）
如果有多个服务提供者，消费者该如何选择？
- 服务消费者利用负载均衡算法，从服务列表中挑选一个
消费者如何感知服务提供者健康状态？
- 服务提供者会每隔30秒向EurekaServer发送心跳请求，报告健康状态
- eureka会更新记录服务列表信息，心跳不正常会被剔除
- 消费者就可以拉取到最新的信息
3.2、 Nacos
Nacos是阿里巴巴的产品，现在是SpringCloud中的一个组件。相比Eureka功能更加丰富，在国内受欢迎程度较高。
Nacos是SpringCloudAlibaba的组件，而SpringCloudAlibaba也遵循SpringCloud中定义的服务注册、服务发现规范。因此使用Nacos和使用Eureka对于微服务来说，并没有太大区别。
3.2.1、服务分级存储模型
一个服务可以有多个实例，例如一个服务可以有:
- 127.0.0.1:8081
- 127.0.0.1:8082
- 127.0.0.1:8083
假如这些实例分布于全国各地的不同机房，例如：
- 127.0.0.1:8081，在上海机房
- 127.0.0.1:8082，在上海机房
- 127.0.0.1:8083，在杭州机房
Nacos就将同一机房内的实例 划分为一个集群。
也就是说，一个服务可以包含多个集群，如杭州、上海，每个集群下可以有多个实例，形成分级模型，如图(user_service是支撑用户信息的服务)：
3.2.2、权重配置
NacosRule负载均衡策略：
- 优先选择同集群服务实例列表
- 本地集群找不到提供者，才去其它集群寻找，并且会报警告
- 确定了可用实例列表后，再采用随机负载均衡挑选实例
实际部署中会出现这样的场景：
服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们希望性能好的机器承担更多的用户请求。Nacos提供了权重配置来控制访问频率，权重越大则访问频率越高。
- Nacos控制台可以设置实例的权重值，0~1之间
- 同集群内的多个实例，权重越高被访问的频率越高
- 权重设置为0则完全不会被访问
3.2.3、环境隔离
Nacos中服务存储和数据存储的最外层都是一个名为namespace的东西，用来做最外层隔离
- nacos中可以有多个namespace
- namespace下可以有group、service等
- 不同namespace之间相互隔离，例如不同namespace的服务互相不可见