一、 认识微服务

二、 微服务演变

  随着互联网行业的发展，对服务的要求也越来越高，服务架构也从单体架构逐渐演变为现在流行的微服务架构。

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的服务互相不可见