《企业级云原生白皮书项目实战》——第六章 云原生最佳实践——6.2 全面容器化之后，来电科技如何实现微服务治——6.2.1 缘起（上）： https://developer.aliyun.com/article/1227887?groupCode=supportservice
6.2.1.2 稳定发布三板斧的诉求
日常发布中，我们常常会有如下一些错误的想法:
•这次改动的内容比较小，而且上线要求比较急，就不需要测试直接发布上线好了。
•发布不需要走灰度流程，快速发布上线即可。
•灰度发布没有什么用，就是一个流程而已，发布完就直接发布线上，不用等待观察。
•虽然灰度发布很重要，但是灰度环境很难搭建，耗时耗力优先级并不高。
这些想法都可能让我们进行一次错误的发布。
阿里巴巴内部有安全生产三板斧概念: 可灰度、可观测、可回滚。所有研发同学必须要掌握发布系统的灰度、观测和回滚功能如何使用。
互联网频繁发布是常态，对于来电科技来说也是如此，系统具备灰度、观测、回滚的能力是微服务系统必须具备的能力，灰度可以说是发布之前的必备流程，也是提升线上稳定性的关键因素。当服务有新版本要发布上线时，通过引流一小部分流量到新版本，可以及时发现程序问题，有效阻止大面积故障的发生。业界上已经有比较成熟的服务发布策略，比如蓝绿发布、A/B 测试以及金丝雀发布，这些发布策略主要专注于如何对单个服务进行发布。
来电科技的微服务数目众多，服务之间的依赖关系错综复杂，如果采用多套环境的硬隔离，会使得成本大幅升高，发布方式变得复杂。有时某个功能发版依赖多个服务同时升级上线。希望可以对这些服务的新版本同时进行小流量灰度验证，通过构建从Ingress网关到整个后端服务的环境隔离来对多个不同版本的服务进行灰度验证，这就是微服务治理中的全链路灰度的能力。
6.2.1.2 自研的挑战
来电科技有考虑过自研微服务治理，来电科技架构师汤长征同学也参与过 Dubbo的开源社区，微服务治理研发对于来电科技来说并不是非常困难的事情，但是自研微服务治理组件还是存在以下必不可少的成本问题：
•接入成本高。
•维护成本高。
•功能单一，不灵活，可扩展性低可定位性变差。
考虑到对生产应用进行微服务治理，微服务框架通常会引入服务治理的逻辑，而这些逻辑通常会以SDK的方式被业务代码所依赖，而这些逻辑的变更和升级，都需要每一个微服务业务通过修改代码的方式来实现，这样的变更造成了非常大的接入与升级成本。同时需要对开源的服务框架做治理功能的研发，就意味着需要出人力对微服务治理的组件进行管理与运维，同时自建会使得功能非常贴近业务，也意味着功能将会做得比较薄比较单一，未来的可扩展性就显得比较弱。同时全链路灰度的实现技术细节也是非常之多，动态路由，节点打标，流量打标，分布式链路追踪，技术的实现成本高。由于 Dubbo、Spring Cloud 等服务框架本身的复杂性，同时随着微服务数量逐步增多，链路越来越长，相关的微服务治理问题的定位与解决也成了让人头疼的问题，如果有 Spring Cloud Alibaba、Dubbo 等专业的团队支持，微服务化深入也会变得更加从容。
