微服务注册

不同的微服务开发框架如何使用服务中心和配置自己的注册信息,同时也会介绍微服务和注册中心之间交互有关的配置项。微服务注册成功后,可以在ServiceComb引擎使用微服务目录、微服务实例列表、微服务依赖关系等功能。

Spring Cloud

Spring Cloud使用服务注册,需要在项目中增加依赖:增加依赖详情

如果项目已经直接或者间接包含这个依赖,则无需添加。Java Chassis包含一些配置项。这些配置项的值影响在服务中心注册的基本信息,以及微服务和服务中心之间的交互,比如心跳等。

Java Chassis

Java Chassis使用服务注册,需要在项目中增加依赖:增加依赖详情

Java Chassis注册的实例地址信息、监听地址,和配置项servicecomb.service.publishAddress指定的发布地址有关。服务监听地址的配置项是servicecomb.rest.address和servicecomb.highway.address,分别对应rest传输方式和highway传输方式的监听地址。

微服务配置中心

配置中心用来管理微服务应用的配置。微服务连接配置中心,能够从配置中心获取配置信息及其变化。配置中心还是其他微服务管控功能的核心部件,比如服务治理规则的下发,也是通过配置中心实现的。

ServiceComb引擎支持的配置中心为:config-center和kie。

说明:

当ServiceComb引擎版本为1.x时,其配置中心为config-center。

当ServiceComb引擎版本为2.x时,其配置中心为kie。

不同微服务开发框架使用配置中心的一些开发细节,包括如何配置依赖、连接配置中心有关的配置项等,并简单的介绍微服务应用中如何读取配置和响应配置变化。

ServiceComb引擎使用kie作为配置中心。

微服务默认会读取配置中心应用配置、服务配置、自定义配置。应用配置指环境、应用和微服务相同的配置;服务配置指环境、应用、微服务名称和微服务相同的配置。微服务可以在配置文件中指定一个特定的label及label值,自定义配置指label及label值与微服务相同的配置。

简单的场景,可以使用应用级配置和服务级配置。应用级配置被该应用下的所有微服务共享,是公共配置;服务级配置只对具体微服务生效,是独享配置。

复杂的场景,可以通过使用customLabel和customLabelValue来定义配置。例如某些配置,是对所有应用共享的,那么就可以使用这个机制。在配置文件增加配置:增加配置详情

ServiceComb引擎使用config-center作为配置中心。

微服务默认会读取配置中心全局配置、服务配置。全局配置指环境和微服务相同的配置;服务配置指环境、应用、微服务名称和微服务相同的配置。

ServiceComb引擎只支持key-value的配置项。如果用户需要使用yaml格式的配置文件,可以使用具体SDK提供的fileSource功能。通过在配置文件中指定fileSource的key列表,SDK会将这些key对应的value全部当成yaml解析。以Spring Cloud为例,在bootstrap.yml中增加配置项:配置项详情

微服务治理

服务治理是一个非常宽泛的概念,一般指独立于业务逻辑之外,给系统提供一些可靠运行的系统保障措施。针对微服务场景下的常用故障模式,提供的保障措施包括:

负载均衡管理:提供多实例情况下的负载均衡策略管理,比如采用轮询的方式保障流量在不同实例均衡。当一个实例发生故障的时候,能够暂时隔离这个实例,防止访问这个实例造成请求超时等。

限流:流控的主要目的是提供负载保护,防止外部流量超过系统处理能力,导致系统崩溃。流控还被用于平滑请求,让请求以均匀分布的方式到达服务,防止突发的流量对系统造成冲击。

重试:重试的主要目的是保障随机失败对业务造成影响。随机失败在微服务系统经常发生,产生随机失败的原因非常多。以Java微服务应用为例,造成请求超时这种随机失败的原因包括:网络波动和软硬件升级,可能造成随机的几秒中断;JVM垃圾回收、线程调度导致的时延增加;流量并不是均匀的,同时到来的1000个请求和1秒内到来的1000个请求平均分布对系统的冲击是不同的,前者更容易导致超时;应用程序、系统、网络的综合影响,一个应用程序突然的大流量可能会对带宽产生影响,从而影响到其他应用程序运行;其他应用程序相关的场景,比如SSL需要获取操作系统熵,如果熵值过低,会有几秒钟的延迟。 系统不可避免地面临随机故障,必须具备一定的随机故障保护能力。

隔离仓:隔离仓通常针对系统资源占用比较多的业务进行保护。比如一个业务非常耗时,如果这个业务和其他业务共享线程池,当这个业务被大量突发访问时,其他业务都会等待,造成整个系统性能下降。隔离仓通过给资源占用比较多的业务分配独立的资源池(一般通过信号量或者线程池实现),避免对其他业务造成影响。

降级:降级治理是在业务高峰期时,需要临时减少对于目标服务的访问,达到降低目标服务负载;或者屏蔽对于非关键服务的访问,保持本服务的核心处理能力的治理措施。

服务治理的复杂性在于没有任何治理措施是适用于所有场景的。对于一个应用场景工作良好的治理手段,在另外一个场景可能成为问题。在业务运行周期,根据业务运行状态和指标,动态的更新治理策略非常重要。

在业务系统中使用服务治理,通常包括下面几个步骤:

1、开发业务。这个过程一般比较少关注服务治理的内容,以交付业务功能为重心。微服务开发框架针对常用的系统故障,一般都默认提供了保障措施,选择合适的微服务开发框架,可以节省DFx的时间。

2、性能测试和故障演练。这个过程中会发现非常多的系统不稳定问题,服务治理的策略会在解决这些问题的过程中应用,并写入配置文件作为应用程序缺省值。

3、业务上线运行。上线运行的过程中碰到未考虑的场景,需要采用配置中心动态调整治理参数,以保障业务平稳运行。

上面的3个步骤在整个软件生命周期会不断迭代完善。描述如何使用所有的治理能力是复杂的,ServiceComb引擎针对不同的微服务开发框架,提供了一个统一的基于流量特征的服务治理能力。如果使用微服务框架开发应用,在应用托管后启动应用,微服务会自动注册到对应的ServiceComb引擎,您可以到微服务引擎控制台进行服务治理的相关操作请参考治理微服务

流量标记限流、容错、熔断、隔离仓、负载均衡、降级、错误注入、自定义治理、黑白名单等详情信息:点击此处前往详情

微服务灰度发布

为保障新特性平稳上线,可以先选择少部分用户试用,待新特性成熟以后,再让所有用户使用。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以减少其影响。

本章节描述的灰度发布是指Java Chassis和Spring Cloud微服务开发框架提供的功能,只能够通过配置下发使用。

Spring Cloud

Spring Cloud使用灰度发布,需要在项目中增加依赖。如果项目中已经直接或者间接引入依赖,无需重复引入依赖详情

Java Chassis

Java Chassis使用灰度发布,需要在项目中增加依赖。如果项目中已经直接或者间接引入依赖,无需重复引入。依赖详情

微服务仪表盘

仪表盘提供一些基础的微服务运行监控能力。微服务通过SDK上报运行状态数据,上报的数据内容包括请求统计数据,比如请求数、时延、错误率等,还包括和治理有关的一些状态,比如熔断状态等。

Spring Cloud使用仪表盘,不需加入依赖,可直接使用。Spring Cloud包含一些配置项:配置项详情,指定仪表盘上报地址等信息。

Java Chassis使用仪表盘,需要在项目中增加如下依赖:依赖详情

如果项目已经直接或者间接包含这个依赖,则无需添加。Java Chassis包含一些配置项:配置项详情,指定仪表盘上报地址等信息。

微服务安全认证

开启了安全认证的ServiceComb引擎专享版,通过微服务控制台提供了基于RBAC(Role-Based Access Control,基于角色的访问控制)的系统管理功能。权限与角色相关联,您可以使用关联了admin角色权限的帐号创建新帐号,根据实际业务需求把合适的角色同帐号关联。使用该帐号的用户则具有对该微服务引擎的相应的访问和操作权限。

ServiceComb引擎专享版开启了安全认证之后,所有调用的API都需要先获取token才能调用,认证流程请参考服务中心RBAC说明。

开启了安全认证的ServiceComb引擎专享版,在使用安全认证前需要完成以下工作:

1、创建安全认证帐号名和密码

2、配置微服务安全认证的帐号名和密码

微服务管理教程视频

微服务引擎CSE

04:38

微服务引擎CSE

微服务引擎CSE

03:29

微服务引擎CSE