作者：十眠、流士
微服务(MicroServices) 架构是一把双刃剑，随着微服务架构复杂化，在大规模之下，再小的问题都会牵一发而动全身，因此微服务架构带来的效率、稳定性问题很可能会远大于微服务本身带来的架构红利。
近日，阿里云 MSE 微服务治理重磅发布企业版，微服务治理能力覆盖从流量防护到流量隔离与恢复，从开发联调到发布上线等各个场景，帮助企业快速构建完整微服务治理体系。
MSE 微服务治理希望能够帮助企业客户打造永远在线的业务。
微服务治理是微服务改造深入到一定阶段之后的必经之路
随着微服务技术的发展，微服务的概念早已深入人心，越来越多的企业开始选择微服务架构来开发自己的业务应用，因为微服务架构可以让业务的迭代更加高效。软件架构的核心挑战是解决业务快速增长带来的系统复杂性问题，当我们照着微服务架构将业务进行解耦的过程中，微服务应用的数量会逐步增多，调用的链路也变得越来越长，服务和服务之间的调用和依赖关系也变得愈加复杂。
在这个过程中，如果我们不对我们的微服务进行恰当的治理，那么由于微服务间复杂的依赖关系，会导致再小的技术问题被放大，引发的效率、稳定性问题可能会远大于微服务架构本身带来的架构红利。在企业进行微服务化到一定程度后，微服务治理是企业必然要面对的一个阶段。
云原生场景下微服务治理复杂度进一步提升
随着企业微服务化进程的逐渐深入，微服务的云原生化逐步进入深水区，在这个微服务深化的过程中，大家也逐渐意识到微服务治理的复杂度，下面我们将微服务治理要解决的问题简单分成三个方面，分别是效率，稳定和成本。
效率
- 在开发阶段，我们需要考虑的是，业务应用上云之后，如何让本地开发的应用很好的部署云上的业务进行联调。通常我们的微服务不可能在本地完整地部署一整套系统，所以本地开发的应用只是整个微服务链路的一小部分，这包括我们的流量需要能够轻松的从云上引导到本地，便于我们做开发调试，或者我们在本地能够很方便的调用云上部署的微服务进行联调。这在微服务上云之后，变的比原来在自身机房进行开发联调更加困难。
- 在线上运维方面，我们通常需要频繁的对微服务进行变更，这些变更通常就会引发一系列的问题，例如在白天高峰期做发布，通常都会导致业务流量出现损失，我们的研发人员不得不选择在晚上业务低峰期做变更。
- 微服务框架通常会引入服务治理的逻辑，而这些逻辑通常会以 SDK 的方式被业务代码所依赖，而这些逻辑的变更和升级，都需要每一个微服务业务通过修改代码的方式来实现，这样的变更造成了非常大的升级成本。
- 进入云原生体系之后，以 Kubernetes 为主的云原生体系强调集群之间的灵活调度型，以 POD 为单位任意的调度资源，在被调度后 POD 的 IP 也将相应的发生变化，传统的治理策略都会面临失效的问题，如何能让服务治理体系更加适应云原生体系，也是我们需要解决的问题。
稳定
- 稳定大于一切，在微服务上云之后，业务高可用是我们必须要解决的问题，因此通常会在同一个地域的多个可用区内进行部署。当然，我们的业务不仅需要在同一个地域里保证高可用，也需要考虑一个地域出现问题的时候，保证业务的高可用，这时我们就需要考虑业务实现同城双活，甚至是异地多活，这对我们来说都是需要考虑的问题。
- 微服务之间的调用也需要更加的安全可信，近期层出不穷的安全漏洞，一定程度上也反应出当前上云阶段在安全方面暴露出的问题还是非常多，每次安全漏洞出现之后，中间件 SDK 的升级也是困扰业务多年的问题；同时，一些敏感的数据，即使在数据库层做了非常多的权限管控，由于微服务被授予了数据访问的较高权限，如果微服务的调用被恶意共计，也可能会造成敏感数据的泄露。微服务之间的调用需要更加可靠可信。
成本
- 当我们在业务面临极速增长的流量时，迫切的需要快速的弹性，补充更多的资源以承载业务的高峰；当我们进入业务低峰的时候，又希望能够缩小容量，节省资源，因此云产品提供的快速灵活的弹性机制，是微服务上云之后一项急需的能力。
自研微服务治理的挑战
来电科技有考虑过自研微服务治理，来电科技架构师 汤长征 同学也参与过 Dubbo 的开源社区，微服务治理研发对于来电科技来说并不是非常困难的事情，但是自研微服务治理组件还是存在以下必不可少的成本问题。
- 接入成本高
- 维护成本高
- 功能单一，不灵活，可扩展性低
- 可定位性变差
上文虽然 cue 到了来电科技，其实不仅仅是来电科技，这些问题是云上企业考虑如何实现微服务治理过程中都要面临的问题。
考虑到对生产应用进行微服务治理，微服务框架通常会引入服务治理的逻辑，而这些逻辑通常会以 SDK 的方式被业务代码所依赖，而这些逻辑的变更和升级，都需要每一个微服务业务通过修改代码的方式来实现，这样的变更造成了非常大的接入与升级成本。同时需要对开源的服务框架做治理功能的研发，就意味着需要出人力对微服务治理的组件进行管理与运维，同时自建会使得功能非常贴近业务，也意味着功能将会做得比较薄比较单一，未来的可扩展性就显得比较弱。同时全链路灰度的实现技术细节也是非常之多，动态路由，节点打标，流量打标，分布式链路追踪，技术的实现成本高。由于 Dubbo、Spring Cloud 等服务框架本身的复杂性，同时随着微服务数量逐步增多，链路越来越长，相关的微服务治理问题的定位与解决也成了让人头疼的问题。来电科技表示如果有 Spring Cloud Alibaba、Dubbo 等专业的团队支持，微服务化深入也会变得更加从容。
MSE 微服务治理助力企业构建完整微服务治理体系
MSE 服务治理以无侵入的方式提供了全链路灰度、流量防护、离群实例摘除、金丝雀发布、微服务治理流量可观测等核心能力，相比自建提供了丰富的差异化能力，能力覆盖开发态、测试态、运行态的微服务全生命周期，无缝支持市面上近五年来全部 Spring Cloud 跟 Dubbo 框架，以更经济的方式、更高效的路径帮助企业在云上快速构建起完整微服务治理体系，有效提升微服务应用的开发效率和线上稳定性。
MSE 微服务治理企业版重磅发布
阿里云 MSE 微服务治理在原有基础版、专业版之上，推出了企业版，提供微服务应用以及常用网关的流量管控与容错能力，从流量控制、并发控制、熔断降级、自适应保护、热点防控等多个维度来保障业务的稳定性，帮助用户很好地应对流量激增或是服务依赖不稳定问题。
在微服务网关层，比如 Zuul，Spring CloudGateway，用户可设置规则进行入口流量防护。在应用层，可进行接口级粒度的防护，支持单机限流、集群限流、分钟小时限流多种限流方式。除了大流量的冲击，第三方服务出现问题时，有时会导致接口响应时间变长，线程资源无法释放等问题。用户可以针对弱依赖接口配置熔断规则，达到不稳定条件时自动熔断。对于非关键接口可提前主动降级，从而避免单点服务异常导致整体不可用。另外流量防护支持自适应系统保护，可根据 CPU、LOAD 等系统资源指标，设定系统保护规则，防止雪崩。同时也可以对自动识别出来的慢 SQL 语句配置隔离规则，限制其并发执行数，防止数据库连接池被打满而影响正常调用。
企业版还支持 QPS、响应时间、异常、CPU/load 等指标的秒级监控能力，并针对这些指标提供提供了机器维度、接口维度、集群维度的秒级流量水位分布的分析功能，方便用户监控防护效果并指导规则配置。
新特性：应用配置
MSE 服务治理中心还增加了应用配置能力，帮助用户动态管理代码中的配置项，可使用在多种业务场景中。一是在业务逻辑预埋功能开关，例如动态开启某个促销活动、将某些耗时操作降级等；二是无须应用重启即能调整应用操作级别，比如线上修改日志级别，指定 A/B Test 路径，线程池配置等；三是 List、Map 等复杂类型的结构化内容推送，如定时推送大促商品名单，统一发送优惠卷客户名单等。
尾
微服务治理作为企业微服务深化的必经之路，MSE 微服务治理围绕着微服务体系持续打磨建设开箱即用的治理能力；一方面我们选择全面拥抱开源，客户不需要改变业务的现有架构，随时可上可下，没有绑定；另一方面我们旨在将阿里巴巴多年技术沉淀与最佳实践以产品化的方式输出给云上客户。
点击“此处”，即可观看 MSE 微服务治理企业版发布相关视频！
