如何做网站内链,wordpress redis 缓存,企业管理培训课程推广,网站建设方案协议书目录 一、线上治理
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.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 runtimefunc 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; i5; 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按照之前的经验值基数较小可以加上固定时间的偏移如550ms具体根据实际情况设置如基数较大时可以使用固定倍数的偏移如1.11.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 平台化、产品化
平台化、产品化的微服务基础设施可以将服务治理能力通过开放平台赋能给更多的微服务用户通过微服务基础设施的产品化可以加快微服务基础设施的创新。 好了本次内容就分享到这欢迎大家关注《微服务架构》专栏后续会继续输出相关内容文章。如果有帮助到大家欢迎大家点赞关注收藏有疑问也欢迎大家评论留言
