本文主要是介绍微服务架构-线上治理、线下治理与架构演进，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目录
一、线上治理
1.1 概述
1.2 线上预案体系
1.2.1 概述
1.2.2 变更引起的故障
1.2.3 流量和容量变化引起的故障
1.2.4 依赖故障
1.2.5 机房、网络等硬件和环境故障
1.2.6 其他
1.2.7 故障的场景化
1.3 基于Metric的预案自动触发
1.4 治理参数动态调整
1.4.1 举例说明
1.4.2 解决方案
二、线下治理
2.1 概述
2.2 链路稳定性治理
2.2.1 链路风险分析的重要性
2.2.2 超时和SLA风险
2.2.3 强弱依赖或重试风险
2.2.4 集群或拓扑风险
2.2.5 链路调用风险
2.2.6 链路风险分析的方法论思考
2.3 架构与资源治理
三、架构演进
3.1 服务治理演进
3.1.1 概述
3.1.2 微服务服务框架存在的问题
3.1.3 解决方案
3.1.3.1 远程Proxy方式
3.1.3.1.1 方案阐述（远程API网关）
3.1.3.2 基于智能客户端的服务框架
3.1.3.2.1 方案阐述
3.1.3.3 本地Proxy（本地网关Sidecar）
3.2 理想的服务治理架构
3.2.1 标准化
3.2.2 配置化
3.2.3 服务化
3.2.4 平台化、产品化
一、线上治理
1.1 概述
线上治理是根据量化分析的结果，通过相应的预案对线上服务的运行状况进行调整，保证线上服务正常运行，接下来讨论线上服务常见的预案，以及如何保证预案的自动触发和自动调整。
1.2 线上预案体系
1.2.1 概述
故障快速定位和止损的理想处理方式是将故障定位和预案执行打通，当出现故障时，能够判断出故障的大体类型以及对应的预案，并触发预案的自动执行。
当然实际的故障处理过程中有很多地方需要考虑，虽然并不是所有故障都能提前建立相应的预案，但我们可以根据历史故障和一些先验知识将故障进行归类，建立相应的预案。另外，建立预案时应尽量方便执行和触发，如果不方便执行，很难短时间内处理故障，最关键的问题是判断预案触发的时机，以及当前是否应该执行预案。
线上服务稳定性故障大体可以归类为如下原因。
1.2.2 变更引起的故障
变更是稳定性故障的最主要来源，系统广义的变更源很多，最常见的服务变更一般包含应用变更、配置变更和数据变更。除了服务变更之外，环境和硬件的变化，比如网络带宽变化、机房链路变化等，也可以归为广义的变更范畴。
1.2.3 流量和容量变化引起的故障
这类故障对应于之前稳定性保障中分析的输入流量突变，如果服务提前没有足够的应对机制，会导致一定的稳定性隐患。
1.2.4 依赖故障
依赖服务故障会影响调用依赖服务的上游服务，依赖服务故障又分为强依赖服务故障和弱依赖服务故障，这两者会有相应的处理方式。
1.2.5 机房、网络等硬件和环境故障
硬件和环境故障的特点是没有办法预测，随机性和偶然性因素很大，并且一旦发生往往是系统级别的问题，会产生很严重的后果。
1.2.6 其他
比如ID生成器溢出导致的故障。
1.2.7 故障的场景化
故障的场景化是指根据上述稳定性故障的大类，再细化出一些方便识别判断的场景，比如入口流量突增、接入层故障、强依赖服务故障、弱依赖服务故障等细分的场景。划分这些场景的目的是发生故障时，进一步识别故障的根因（不一定是最根本原因，而是从止损的角度进行归类）。因此可以对那些比较容易通过可观测性指标判断出故障的场景类型，并且方便制定相应的场景化预案的故障，进行场景化归类。
1.3 基于Metric的预案自动触发
对于降级、限流和冗余切流这几类比较明确的场景，可以基于Metric进行故障判断，并且和预案自动打通，以依赖服务故障为例，可以根据Metric成功率指标同环比变化，判断依赖服务是否有异常，如果通过Metric发现当前确实有异常，先查询变更管理平台，依赖服务当前是否有相关的变更操作。如果有变更，建议依赖服务接口人立即进行变更回滚操作；如果没有变更操作，再判断当前对依赖服务的调用是强依赖还是弱依赖，如果是弱依赖，可以启动自动降级预案对依赖服务进行降级，如果是强依赖，降级肯定不能解决问题，可以通过预先制定好的冗余切换预案，启动服务级、集群级或者机房级别的流量切换。
基于Metric的场景和预案打通，目标是朝着故障定位自动化和智能化的方向演进，但需要根据实际情况逐步推进，对于一些不太容易判断的场景，建议谨慎操作，避免可能的误判，同时要定期对预案进行演练，保障预案触发的有效性。
1.4 治理参数动态调整
限流降级和切流是服务治理的3个利器，分别解决上游、下游和服务自身故障问题。这些服务治理特性和实现本身并不复杂，使用时的关键和难点在于触发的具体时机，比如什么时候启动限流、什么情况下启动降级等，下面以限流为例详细讨论如何设置治理参数以及限流的触发时机。
1.4.1 举例说明
以登录服务为例，登录过程中需要使用加密算法对密码进行校验，一次登录过程CPU耗时1s，登录服务线上使用的服务器是40核，因此一台机器上登录服务的QPS大概是40左右。当某一秒有200个请求进到登录服务，我们希望服务可以在接下来的5s内，每秒完成40个请求，这很好理解，也符合常理，因为这样才能达到稳定输出的服务目标。但事实符合我们上面的预期吗，我们以一个简单的golang程序为例来看看。
package mainimport "fmt"
import "golang.org/x/crypto/bcrypt"
import "time"
import "runtime"func test(cost int, id int){fmt.Println(time.Now(), "BEGIN test ", id)code, _ := bcrypt.GenerateFromPassword([]byte("password"), cost)fmt.Println(time.Now(), "END test ", id, code[0])
}
func main() {runtime.GOMAXPROCS(1)for i:=0; i<5; i++ {go test(17, i)}time.Sleep(1e16)
}
程序运行完，结果如下：
2024-05-15 00:24:46.451649842 +0800 CST BEGIN test 1
2024-05-15 00:24:46.451685368 +0800 CST BEGIN test 2
2024-05-15 00:24:46.451693975 +0800 CST BEGIN test 3
2024-05-15 00:24:46.451699783 +0800 CST BEGIN test 42024-05-15 00:25:36.89918498 +0800 CST END test 0 36
2024-05-15 00:25:37.090741796 +0800 CST END test 2 36
2024-05-15 00:25:37.098754534 +0800 CST END test 3 36
2024-05-15 00:25:37.183491458 +0800 CST END test 1 36
2024-05-15 00:25:37.18871652 +0800 CST END test 4 36
结论：
通过观察上面的输出日志，我们可以看出结果并不是每秒稳定输出，而是在一段时间后，这一批请求都在很接近的时间被处理完。和我们上述的预期不太相符。这涉及Golang的协程调度，并不是等到协程运行到阻塞点才交还CPU，这在逻辑上也是正确且应该的，目的是防止协程实现存在问题而将CPU全部消耗掉。但这个逻辑对于CPU密集型的服务而言，在遇到尖峰流量时，就会产生我们不希望的结果。
回到上面讨论过的具体例子，200个请求进入服务后，如果上游设置的超时时间比5s短，这200个请求对外就全部超时了。也就是说，只要有超出CPU处理能力范围的大流量到达登录服务时，如果不做特殊处理，这些请求无一例外全部超时。这个问题会影响CPU密集型的Golang服务，采用类似调度策略的Java/C++服务也有类似问题。
1.4.2 解决方案
具体如何解决呢？很容易想到用单接口限流来解决。通过处理能力计算出每秒最多能接收的请求量，超出就抛弃请求，防止大流量对服务质量的冲击。这就是尖峰限流。对于登录服务来说，可以把限流阈值设置为40QPS，超出部分就丢弃，通过单接口限流解决这个问题，但这个方案的问题也很明显：如果高CPU占用接口在梳理时被遗漏了，该接口消耗了绝大多数CPU，导致限流失效；同时新增加的接口，靠人和经验来评估限流值，也很容易遗漏设置。
继续思考，我们会发现这个方案最重要的问题：接口不止有一个，而它们使用相同的CPU资源。那每个接口允许的限流值怎么设置，到底要给其他接口留多少余量呢？
以登录服务为例，如果设置成40QPS就是不给其他接口留余量，但由于前述的Golang CPU调度特性，极端情况下只要有其他接口流量，所有登录请求都会超时，整体有效吞吐变成零。那应该设置成多少，20、10？我们会发现无论多少都不适合，因为不知道极端情况下流量特点到底是什么样的。也就是说，单接口限流可以满足突发流量的需求，但不足以完成极端情况下的流量调度需求。如果一个服务同时有I/O消耗型接口与CPU消耗型的接口，通过简单的接口限流方案（即手工设置所有接口的最大QPS）无法兼顾效率与吞吐，且存在严重的维护问题（说不定哪天某个新接口就忘记设置限流了）。
对于同时有I/O消耗型接口与CPU消耗型接口的服务，我们可以通过部署拆分将CPU消耗型接口和I/O消耗型接口独立部署，让它们互不影响。但这样并不能从根本上解决问题。因为计算型的接口不止一个，总不可能每一个计算型接口都单独部署集群。只要设置过的人都会遇到这个疑惑：到底要设置成多少合适？每个接口的限流设置稍微高一点，请求压力一大系统就可能总体过载。因此考虑到安全原则，实际情况中接口限流都是设置成非常安全但低效的阈值，但这样会导致大量的机器资源浪费，因此，我们必须抛弃这种安全但低效的阈值管理方式，寻找一种更加科学合理的流控方式。
再细化一下流控的需求，我们需要的流控方案应该是：足够安全、高效，能保证持续吞吐，能充分利用CPU的。其中的核心是持续吞吐和高效。最后实际产出的技术方案是多重级联的自动流控，具体设计思路大体如下。
- 带反馈机制的动态限流
设计思路：任何接口在极限流量下，只要超出处理能力，就一定会出现接口超时，但因为有突发流量的控制，对外吞吐能力是稳定的。只要超时率超过一定比例，就启动阈值的上升和下降，控制进入系统的请求包数量。
- CPU限制
为了控制程序对CPU的使用，留给其他系统进程（如各种Agent），同时为了防止通过流量阈值一次进入太多的请求，我们控制最多起40个Golang协程用于处理CPU消耗型的接口（这也是我们的突发限流）。其他请求列队等待。这里面需要注意的是，出队时要注意时间，如果请求已经超时需要直接抛弃，但这个时间不需要很长，同时需要结合SLA，考虑在秒级平缓瞬时请求流量。
- 过载保护
过载保护，即实际采用方案的连接数超过一定阈值就主动拒绝请求。这很容易理解，但里面有个小细节是拒绝的方式：不能简单地忽略请求，而应该快速断开连接或者回复服务器当前太忙消息给调用方。
二、线下治理
2.1 概述
线下治理是根据量化分析的结果，对稳定性治理、架构治理等进行调整，下面从链路治理和架构治理相关的实例出发，看看如何通过量化分析指导线下治理工作。
2.2 链路稳定性治理
2.2.1 链路风险分析的重要性
链路风险分析就是从链路通信的历史数据出发，分析出链路当前存在的风险，减少链路通信的隐患，提高系统的整体稳定性。链路风险分析可以解决的问题域很多，如超时时间设置是否合理、重试次数设置是否合理、服务SLA指标设置是否合理、服务的强弱依赖关系是否符合预期等，服务通信相关的一大部分故障是由于链路风险导致，可以通过链路风险分析的方式提前发现和解决，避免故障的发生。
链路风险分析的基础是链路实时拓扑图和Metric指标，下面会针对几种典型的链路风险，进行详细的分析。
2.2.2 超时和SLA风险
客户端访问服务端的超时时间配置，和实际访问情况不符，是非常常见的一种链路风险。上游服务的超时配置过小，会导致一些本来可以正常返回的请求超时，影响服务的SLA和正常的服务体验；超时配置过大，会导致下游服务故障时上游服务超时等待的时间太长，严重时会把整个系统拖垮。因此，超时设置直接关系到系统的稳定性，需要有相应的机制指导服务的超时设置，并及时发现线上系统中的超时配置隐患。
超时配置风险主要有两种：一种是超时时间和实际不相符；还有一种是上下游的超时设置不匹配，比如有A、B、C 3个服务，服务A访问服务B，服务B访问服务C，但实际业务中经常会遇到服务A访问服务B的超时时间比服务B访问服务C的超时时间小的情况。
上述两种超时配置风险均可以通过链路风险分析的方式解决。思路其实很简单，Service Mesh收集服务间通信的Metric指标数据，通过Metric数据可以分析出服务访问当前的各分位耗时，比如99.99分位耗时是50ms，即99.99%的请求都能够在50ms范围内正确返回，我们只需要根据业务实际情况，把要求的分位耗时（如业务要求4个9的成功率，也就是99.99分位）和超时配置进行比较，如果差异过大，则存在超时配置风险。可以定期将当前存在相应风险的配置通过一定的方式知会业务人员，如果业务人员判断确实有问题，就可以尽快对这个风险进行修复。
实际超时配置修复时，可以使用上述分位耗时作为基数，加上一定的偏移作为Buffer，按照之前的经验值，基数较小，可以加上固定时间的偏移（如5～50ms，具体根据实际情况设置），如基数较大时，可以使用固定倍数的偏移（如1.1～1.5倍）。
SLA风险也可以采用同样的思路进行分析，这里不再详细展开。
2.2.3 强弱依赖或重试风险
微服务之间通信，如果该链路通信失败会导致整个请求处理失败，一般将这两个微服务之间的关系称之为强依赖，反之称之为弱依赖。我们可以基于服务的强弱依赖关系，进行降级、熔断等处理。
强弱依赖服务风险，是指链路通信之间的关系和预期不符。比如，服务A调用服务B的链路是弱依赖，但随着需求迭代业务逻辑发生变化，可能不经意间服务A调用服务B的链路实际上变成了强依赖，但大家仍然按照之前的先验知识，把它当成弱依赖，这就是一个很大的风险点。特别是链路故障时，基于弱依赖的前提进行降级等操作时，就可能会酿成悲剧，导致整个系统不可用。因此需要有相应的机制，定期检测出当前链路关系的风险点。
强弱依赖风险分析可以采用故障注入的思路，但与直接在线上系统进行故障注入和演练不同，为了不影响线上服务的稳定性，可以通过线下环境进行强弱依赖风险检测。具体思路是采用故障注入配合自动化测试，通过Service Mesh获取到系统的拓扑关系图，自然就可以得到所有的调用链路以及具体的链路关系，这个可以称之为基准链路关系表。针对每个调用链路，通过故障注入的方式让链路调用返回失败，构造一个测试用例，在该测试用例基础上执行正常的自动化测试。如果自动化测试成功，证明该链路失败对整个流程没有影响，说明该链路是强依赖，反之是弱依赖。通过这种方式，可以判断出每个链路最新的链路关系，然后和基准链路关系进行比较，如果有差异，说明链路关系发生了变化，产生了新的链路依赖风险。
重试风险也可以采用同样的思路进行分析，这里不再详细展开。
2.2.4 集群或拓扑风险
集群或拓扑风险是风险分析的一个主要来源，之前的工作中遇到过不少集群或拓扑风险的真实案例。比如，某线上集群的一些机器因为保修临时下线一段时间，但机器修复好之后遗漏挂载，导致部分机器白白闲置；服务A调用服务B本来是同机房调用，由于故障或者流量切换演练等原因临时将调用关系切换到调用其他机房的服务B服务，但事后没有切回来，导致服务A调用服务B一直是跨机房访问，影响用户体验和系统稳定性；某服务S线上部署时没有考虑到地理位置因素，将过多的服务节点部署到同一个交换机下，交换机故障时导致服务同时有多个节点不可用，可用节点数不足导致服务雪崩。
集群部署风险或者拓扑风险没有通用的解决思路，需要针对具体的风险增加相应的风险应对措施，以上述列举的服务下的多个节点部署在同一个交换机下为例，一般在同一个交换机下的机器，IP网段信息差不多，可以根据类似的信息，通过程序定期扫描所有的线上集群，根据集群节点的地址信息，判断是否存在拓扑部署风险。
2.2.5 链路调用风险
链路实时拓扑数据是一个宝藏，可以从中慢慢挖掘出链路调用层面的很多风险。比如，当前服务调用超过20个下游服务，扇出过大，不太符合微服务的设计准则，可以考虑是否有必要进行进一步的拆分。
微服务架构中，单个请求的链路特别长时，会带来一定的性能问题，因此可以从全局链路拓扑中将TOP10长的链路，或者链路深度超过6的链路列出来，反馈给业务人员，看看是否有必要进行架构层面的调整。
微服务拆分和设计过程中，建议不要出现两个微服务相互依赖的场景，可以通过链路拓扑图查找当前是否存在成环的链路，如果成环，说明服务之间产生了相互依赖，可以将类似风险反馈给业务人员进行整改。
2.2.6 链路风险分析的方法论思考
链路风险分析是发现风险并对风险进行抽象和建立自动化检测机制的过程，本质上是对稳定性风险进行精细化管理的系统性工程，需要长期持续地建设下去。
发现风险是链路风险分析的第一步，为了能够持续发现系统新的风险，建议将风险分析和稳定性反模式结合起来：
- 根据系统中出现的重大故障，以及之前积累的容易出现故障的一些典型问题，梳理出稳定性反模式，也就是稳定性实践中容易犯的，不应该出现的一些模式；
- 判断这些反模式是否能通过自动化的方式检测出来。
同时为了方便新增风险的检测，可以建立一个完善的风险分析框架，具体包含风险现状、风险改进闭环、风险报告、风险自动通知机制等，新增的风险分析就直接基于框架开发，相当于增加个插件，可以大大提高风险分析的效率。
2.3 架构与资源治理
业务迭代过程中，可能会出现很多临时性的调用关系，调用关系使用一段时间后不再使用，长时间积累下去，可能会导致服务存在不少冗余代码，影响服务的可维护性。我们可以通过实时拓扑图和静态的基准拓扑图进行比较，如果出现基准拓扑图中存在，而实时拓扑不存在的服务调用链路，说明当前链路不再使用，基于实时拓扑和基准拓扑的差异比较，可以考虑将这种冗余调用代码去除。
为了保证变更的质量，服务在新增特性时通常会给它配置相应的特性开关，通过开关来区别不同版本的代码，随着架构的迭代升级，可能会导致不少版本的代码和分支不再使用，我们可以采用和上述冗余链路检测类似的方式。当检测到特性开关判断总是返回特定值时，说明其他分支当前已经不再使用，可以提示相关人员，这类无用代码是否可以移除。
我们也可以从资源调用和使用报表中发现当前服务资源是否有使用不当的地方，比如缓存资源遗漏设置过期时间，缓存资源设置的过期时间过大等；如果存储资源出现过大的对象，或者长期不再使用的数据，也可以反馈给业务方相关人员，以确定使用上是否需要进行调整。
三、架构演进
3.1 服务治理演进
3.1.1 概述
服务治理当前有远程Proxy方式、智能客户端方式以及本地Proxy这3种主要承载方式，下面分别讨论这几种方式的优缺点。
3.1.2 微服务服务框架存在的问题
微服务下的服务框架基本解决了微服务开发和测试的效率问题，业务人员可以把精力聚焦投入到业务需求上面。多语言服务化背景下，服务治理的基础设施的每一次改动和升级，需要多语言框架的同时升级，这里多语言服务框架的开发、测试和维护的开销有很大的工作量。
由于服务框架以Lib的形式存在，和业务代码存在于一个服务里面，会导致做业务需求的业务人员和负责服务治理的基础设施人员之间仍然会有很多沟通和交互，随着组织和团队的扩大，受康威定律的影响，这个沟通成本会变得不可控。
客户端和服务端通信，客户端和服务端都需要有不少服务治理相关的考虑，比如客户端访问服务端时需要考虑服务发现、流量路由、负载均衡、调用熔断、请求降级、mock支持、请求跟踪等诸多特性，服务端也需要考虑限流、降级、安全、统计等。随着业务迭代发展，客户端和服务端需要支持的服务治理特性越来越多，这会影响业务迭代效率。
如何减少多语言接入场景下服务治理基础设施的维护开销，同时减少服务治理基础设施升级对业务的影响，尽量将服务治理和业务解耦，这是微服务架构面前的一个课题。
3.1.3 解决方案
3.1.3.1 远程Proxy方式
3.1.3.1.1 方案阐述（远程API网关）
架构设计上有个不成文的说法，任何软件工程遇到的问题都可以通过增加一个中间层来解决。按照这个说法，可以很自然地想到，微服务架构下，是否可以在客户端和服务端中间增加一个中间层，避免两者直接通信，同时把服务治理相关功能从客户端和服务端代码解耦，移到中间层来，这样服务治理特性的变化收敛在中间代理层，对客户端和服务端透明。远程Proxy方式-API网关就是在这种前提下，被提出来的。
API网关就是用来解决上述微服务治理的效率问题。API网关封装了服务访问和服务治理相关的具体逻辑，客户端只需要使用简单的访问方式，统一访问API网关，由API网关来代理对后端服务的访问，同时由于服务治理特性统一放到API网关上面，服务治理特性的变更可以做到对客户端透明，一定程度上实现了服务治理等基础特性和业务服务的解耦，服务治理特性的升级也比较容易实现。
为了简化客户端的访问方式，对调用方屏蔽集群访问的复杂度，API网关一般会提供一个VIP，调用方直接使用VIP进行访问，由负载均衡设备负责VIP到API网关地址的映射。
API网关和直接使用服务框架相比，优点是业务使用起来很简单，没有什么入门成本，非常容易上手，对业务来说，简单和效率往往是第一位的；同时API网关也可以屏蔽多语言调用方使用方式的差异，避免了微服务框架语言级别的限制，多语言调用方均可以使用简单一致的调用方式访问后端服务，基本解决了多语言的服务治理问题。
当然API网关在提供便捷的服务访问和服务治理能力的同时，相应地也会有一些问题。
- 首先，引入API网关，通信层面会增加一跳；如果是采用简单易用的VIP访问方式，还需要加上用于VIP解析的负载均衡服务这一跳，所以通信层面上比原来直接访问后端服务增加了二跳，性能上肯定会有一定的损耗。
- 其次，通信链路上多一跳就会多一个故障点，会对系统的整体稳定性和可用性有一定的影响。
- 最后，API网关简单易用的同时，灵活性和定制化支持不太好，很难支持复杂的服务治理定制化需求，比如服务如果想支持动态路由切换，API网关支持起来就有点力不从心。
因此，在业务相对简单，或业务线上部署结构不太复杂时，使用API网关是一个很好的选择，可以简化微服务的开发和运维，提高业务迭代的效率。但业务如果发展到比较复杂时，比如生产环境有多个机房，或者同一个机房内部有全流量环境、小流量环境等多套环境，就会有比较多的路由策略需求和动态路由切换需求，这种情况下就需要探索服务层面是否可以有一种对效率和扩展性更好的平衡方式。
3.1.3.2 基于智能客户端的服务框架
3.1.3.2.1 方案阐述
和远程Proxy不同，基于智能客户端的服务框架采用和服务端直连的方式，客户端和服务端直接通信，中间不经过任何节点，不仅性能提升，也增强了稳定性。
服务框架需要支持完善的流量调度和容错设计，同时需要支持常见的服务治理策略，对技术的要求相对较高，对于中小公司来说，开发或维护一款完善的服务框架的开销都是不小的。
除了开发维护成本高之外，服务框架作为Lib和客户端服务绑定在一起，因此是语言相关的，所以每个语言均需要相应的服务框架，这会带来很高的多语言服务治理成本。
另外，由于和客户端服务绑定在一起部署，服务框架的迭代升级相对麻烦，当服务框架进行升级时，使用框架的服务均需要进行升级，对于广泛使用的服务框架来说，这是笔不小的开销，框架和微服务的绑定和耦合，会影响框架自身的迭代和创新。
3.1.3.3 本地Proxy（本地网关Sidecar）
API网关把服务治理相关特性从服务框架中解耦出来，可以提高效率，但灵活性和扩展性稍差；服务框架可以自如地支持各种服务治理需求，但多语言服务治理支持方面会有很大的开销，同时服务治理特性的升级和维护比较困难。因此，是否有一种机制或方式，能兼顾API网关和服务框架各自的优点，在提高业务开发效率的同时，也能很好地支持微服务治理的扩展性和定制化需求，本地网关应运而生。
本地网关又称为Sidecar，通过在每个服务实例对应的本地机器上部署实现服务治理功能的代理，来实现服务治理能力的快速落地。最有代表性的是Netfilx的微服务中间件Prana，初衷是将Netfilx OSS微服务治理套件的能力，通过HTTP API接口的方式，赋能给非Java语言使用，以很小的开销获得Netfilx OSS体系强大的服务治理能力。受到Netflix Prana的启发，Spring Cloud也推出了Spring CloudNetflix Sidecar。
和API网关相比，本地网关的访问方式更为简单。
- 事先给本地网关绑定固定的端口号，业务服务通过“localhost：本地端口号”的方式即可访问，虽然和直接访问服务端相比多了一跳，由于是本地访问，比API网关的性能损耗要小。
- 由于本地网关每个机器上都会有部署，因此API网关单个节点故障对系统稳定性的影响相对较小。
- 本地网关和服务部署在一起，具有感知本地部署环境的能力，方便一些业务或者环境相关的服务治理特性的落地，比如机房级别的动态路由调整等。
从效率和扩展性上看，本地网关和API网关相比，都有着不少优势。那么是否意味着本地网关就是一个没有问题的完美方案呢，其实本地网关最大的问题是运维上的复杂度比较高，本地网关节点很多，并且业务服务对本地网关也是强依赖，因此需要对本地网关的部署、监控、升级、高可用保障等，都有一套完善的机制来保障。由于本地网关对运维的要求比较高，需要有一套完善的运维工具体系支撑，之前很长一段时间，这种模式在一些互联网公司中得到采用，如Netfilx、Airbnb等，并没有大规模应用起来。
3.2 理想的服务治理架构
为了支撑微服务架构，提高微服务迭代效率，理想的微服务基础设施需要具备如下几个特点。
3.2.1 标准化
标准化的微服务基础设施，保证了微服务架构的通用性、可维护性和可移植性，同时基于标准化的微服务基础设施，可以更方便地实现微服务自身的标准化。
3.2.2 配置化
配置化是保障微服务治理和微服务稳定性、敏捷性的关键，理想的微服务基础设施，需要通过统一的治理平台，对服务治理的效果进行可视化度量，同时可以通过可视化界面方便地调整服务治理的策略，即时生效。通过配置化，可以建立服务治理策略调整和反馈的闭环机制，支撑服务治理特性的快速迭代。
3.2.3 服务化
如果可以将微服务基础设施服务化，通过标准化接口获取服务访问和服务治理能力，可以真正做到服务治理对业务的解耦合与透明，实现服务治理和微服务的并行开发和升级。
3.2.4 平台化、产品化
平台化、产品化的微服务基础设施，可以将服务治理能力通过开放平台，赋能给更多的微服务用户，通过微服务基础设施的产品化，可以加快微服务基础设施的创新。
好了，本次内容就分享到这，欢迎大家关注《微服务架构》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！
这篇关于微服务架构-线上治理、线下治理与架构演进的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
