微服务架构介绍

系统架构演变历史

从单体架构到垂直应用架构到分布式架构到SOA架构再到微服务架构等等。

单体架构

更类似于一个形态而不是架构，将所有的逻辑放在一个进程里，其性能高，冗余小，但debug困难，模块之间容易相互影响，模块难以分工，开发困难。

垂直应用架构

其可以按照业务线垂直划分，能够分离不同的业务逻辑，有利于业务的独立开发维护，但不同的业务存在冗余，每个业务也还是单体，具有单体的缺陷。

分布式架构

其抽出业务无关的公共模块，能够达到逻辑复用的条件，实现公共逻辑的复用，但其服务模块可能会导致bug，导致全站瘫痪，调用的关系复杂，不同服务冗余。

SOA架构

其面向服务，具有一个服务中心，具有服务注册及发现的功能，但整个系统是中心化的，需要从上而下设计，重构困难。

微服务架构

彻底的服务化，从下而上的服务搭建，开发效率高，业务可以独立设计，故障隔离，但治理运维复杂，观测困难，安全性不高，系统分布式，具有分布式系统的缺陷。

微服务架构的核心要素

服务治理：服务注册，服务发现，负载均衡

可观测性：日志采集，日志分析，异常报警，链路追踪

安全：身份验证，认证授权，访问令牌

微服务架构原理及特征

基本概念

服务是一具有相同逻辑的运行实体，实例是一个服务中每个运行实体就是一个实例，实例可以对应多个进程，集群是指服务内的逻辑划分，包含多个实例。

服务间通信，对于单体服务，不同模块通信只是简单的函数调用，的那对于微服务，服务间的通信意味着网络传输。

服务注册与发现

//Service A wants to call serviece B.
client:= grpc.NewClient("10.23.45.67:8080")

但我们不可能指定一个固定的IP地址，同时一个服务有多个实例，不能直接写死。

而且本地的DNS存在缓存，会有延迟，负载均衡会出现问题，不支持服务实例的探活检查，域名无法配置端口。

服务实例上线与下线

在下线服务的过程中，如果仍有流量进入，则可能导致服务出现故障，因此，需要优先在服务中心删掉要下线的服务的记录，这样就会停止调用该服务实例，此时就可以下线。

要上线服务，则要先添加服务再上线该实例，同时，在上线新的服务实例时，还要先进行测试。

核心服务治理功能

服务发布

指让一个服务升级运行新代码的过程

在线服务的发布会导致服务不可用，服务抖动等问题

在服务出现问题时可以采用服务回滚。

蓝绿发布，可以先下线一部分服务，对其进行升级，然后上线，再对蓝色服务进行升级，完成后上线，但这种方法要求一半的资源能够处理所有的服务，这种操作更适合在流量低的时候进行操作。

灰度发布，即将线上的一小部分实例进行升级，验证新版本的可用性，再一部分一部分地升级，其要求精确的流量控制，而且回滚困难。

流量治理

在微服务架构下，我们克鲁伊基于地区，集群，实例，请求等维度，对端到端流量的路由路径进行管理。

负载均衡

使用Load Balance分配请求在每个上下游实例上的分布 常见的LB策略有：Round Robin,Random,Ring Hash等。

稳定性治理

线上服务总会出现问题，与程序的正确性无关。 但仍可能遇到网络攻击，流量突增，机房断电，光纤被挖等等。为应对这些问题，我们多采用限流，熔断，过载保护，降级等方法保护服务。

字节服务治理实践

重试的意义

本地的函数调用，可能会出现非法参数，OOM，边界case等，出现错误多没有重复调用的必要，但对于远程函数的调用，可能由于网络抖动，下游高负载超时，下游熔断等，因此其具有重试的价值。

重试可以有效得避免偶发的错误，提高SLA，同时，其对于偶尔耗时长的请求，重试有机会提前返回。

重试的难点

但在实际使用过程中，通常不默认开启重试，因为其可能会导致重试风暴等问题，超时设置的配置也是一个难点，重试雪崩也可能因为多次重试诱发，如a实例要重试3次，此时调用了b实例，但b也会进行3次重试，再调用c，c又会进行3次重试，此时就已经导致了27次请求。

重试策略

可以限制重试比例，设定一个重试比例阈值，重试次数不能超过请求比例的百分比，这样就可以有一个重试的预期。

对于可能超时的请求发，重新向另一个下游发送一个相同的请求，并等待先到达的响应。

以上就是关于微服务的基础介绍。