qq_25409421的博客

线上治理是根据量化分析的结果，通过相应的预案对线上服务的运行状况进行调整，保证线上服务正常运行；线下治理是根据量化分析的结果，对稳定性治理、架构治理等进行调整；服务治理当前有远程Proxy方式、智能客户端方式以及本地Proxy这3种主要承载方式；为了支撑微服务架构，提高微服务迭代效率，理想的微服务基础设施需要具备4个特点

可见可观测是服务治理反馈机制的第一步，只有获取到足够多有价值的数据，才能对服务的运行状态进行分析和控制。本文从服务可见性、变更可见性、服务可观测性三个方面阐述可见可观测的服务治理。量化分析体系是基于数据对系统进行量化、定位和分析，然后产生相应的治理措施，指导线上治理和线下治理，本文从度量、定位和风险分析这几个维度对量化分析体系进行展开讨论。

为了解决微服务改造后带来的一系列问题，我们需要通过正向治理相应的治理手段。正向治理只要围绕效率、稳定性和效果方面的治理工作展开讨论。微服务架构的初衷主要是建立一个方便快速迭代和演进的架构，帮助业务实现方案快速落地和试错，因此在微服务研发流程上，需要重点关注两个事情：如何支撑业务特性快速落地，如何建立业务效果的闭环反馈机制。在治理效果方面，我们主要从服务的配置化和效果评估体系两个方面来说明

在单体服务时代并没有服务治理的概念，随着单个服务慢慢演变和拆分为众多微服务组成的系统，服务提供者与服务使用者之间如果没有明确的契约和规范，开发、测试和运维过程中会带来很大的沟通成本。本文首先介绍微服务治理的几个维度，接着说明微服务治理的目标和愿景、微服务治理的工作范畴，最后提到了微服务治理闭环体系。

在云原生时代，企业从单体架构发展到分布式架构，广泛采用微服务、容器、Serverless等部署方式，IT基础设施变得愈发不可控。这导致传统的监控技术和工具很难跟踪这些分布式架构中的通信路径和相互依赖关系，更别提排查问题并定位根本原因了。当监控无法再单独以运维的视角、被动地解决故障为目标，而要追随IT架构的改变和云原生技术的实践，融入开发与业务部门的视角，具备比原有监控更广泛、更主动的能力，“可观测性”概念诞生了。今天通过我的文章，让我们一起来揭开它的神秘面纱。

在传统应用架构开发模式下，我们的配置文件往往采用本地静态配置，基于xml、properties等格式，采用远程DB存储、远程GIT存储等方式实现简单的配置管理，但是面对微服务架构模式的开发场景下，传统配置模式面临着诸多问题，比如配置修改困难、缺少安全审计和版本控制能⼒、⾮⽣产配置带到⽣产环境，引发生产事故等。所以我们就需要一个能解决微服务场景下的应用配置解决方案，本文就围绕微服务应用配置主题探讨下相关的解决方案。

绝⼤多数的软件应⽤⽣产安全事故发⽣在应⽤上下线发布阶段，尽管通过遵守业界约定俗成的可灰度、可观测和可滚回的安全⽣产三板斧，可以最⼤限度的规避发布过程中由于应⽤⾃身代码问题对⽤户造成的影响。但对于⾼并发⼤流量情况下的短时间流量有损问题却仍然⽆法解决。因此，本文章将围绕发布过程中如何解决流量有损问题实现应⽤发布过程中的⽆损上下线效果相关内容展开⽅案介绍。

技术不断在更新迭代，相对应的软件架构也在不断迭代和演进，从一开始的单体架构、集群架构到分布式架构，再到现如今的SOA架构、微服务，以及Serverless架构等，企业为了应对自身业务的快速发展，不断对架构设计进行调整和优化，在享受微服务架构带来的技术红利的同时，也面临诸多挑战。比如请求链路的复杂度提高，新功能发布时会涉及到多个微服务同时变更，并且业务的服务之间依赖错综复杂，频繁的服务发布、以及服务多版本并⾏开发导致流量治理规则⽇益膨,给整个系统的维护性和稳定性带来了不利因素。本文就来探讨下微服务场景发布方案