一、 携程微服务产品的发展历程 
携程微服务产品起步于2013年。最初，公司基于开源项目ServiceStack进行二次开发，推出.Net平台下的微服务框架CServiceStack。
2014年，公司推出Java平台下同CServiceStack完全互通的自研微服务框架Baiji和第一代服务注册中心。该服务注册中心后续经历多次重构，目前使用的已是第四代产品。
2017年,公司正式引进开源产品Dubbo，推出整合携程治理能力的CDubbo框架。该框架最初基于Dubbo 2.5.4版本进行二次开发，经历多次版本升级后，目前使用Dubbo 2.7.7版本。
2020年,公司正式开始探索落地Service Mesh项目。目前，相关产品已经在生产环节正式落地，正在进行接入推广工作。
携程微服务产品情况复杂，主要在于以下四点：
• 线上同时运行着三种微服务框架产品。
• 同时采用HTTP和Dubbo两种通信协议。
• 采用完全自研的基础设施，包括注册中心和配置中心。
• 现存8000多个线上服务，实例数超过10万个。
随着研发的深入，我们团队主要遇到了以下三点问题：
• 维护多个功能类似的中间件产品工作量较大，保证产品之间功能对齐需要花费大量的精力。
• 由于产品以SDK公共依赖包的形式集成在业务应用内，进行版本升级需要业务方配合，推动升级比较困难，版本长尾问题严重。
• 由于团队工作精力和技术栈的限制，只有少数几个语言平台上存在SDK支持，不利于小众语言用户使用微服务产品。
二、 携程的云原生微服务架构设计
由于线上集群已初具规模，如何平滑过度和迁移框架成为关键问题。彻底抛弃现有基础设施，一步到位实现全面云原生，不仅实施难度较大，项目周期也比较长。
因此，项目决定采用“小步快走”的方式。首先保证代码完全向后兼容，其次保证整体架构支持业务应用迁移，提升接入容错率。
项目进行架构设计时，遇到了三个关键的问题。
• 数据权威问题
常见的Service Mesh实践以K8S为准则，将所有的数据保存在K8S内，但平台现有数据大部分保存在自研的注册中心和配置中心内。
有方案提出采用两条推送路的方式，云内数据保存在K8S内，云外数据保存在现有注册中心里，通过外部工具或组件实现双向同步。但双向同步复杂度较高，既要保证数据的准确性和实时性，也要保证同步不成环。
因此，出于架构简便性考虑，项目最终选择保持注册中心数据权威地位不变，通过外部组件将数据写入K8S。
• 边界划分问题
目前的项目部署体系是一个Region内包含多个Zone，一个Zone内又包含多个K8S集群，集群之间网络互通。但由于故障隔离的需要，数据最好保持在Zone内收敛，使实例信息不需要进行跨Zone同步。
Zone内收敛存在的问题是当调用方发起跨Zone调用时，需要经过网关进行中转。这种调用方式和现有的调用链路存在差异，会提高计算复杂度。
因此，项目最终选择保持现有工作模式不变，使得调用方能够获取Region内所有的Zone服务实例，保持数据在Region内透明。
• 技术选型问题
过去，项目研发产品大部分采用自研模式，通过整个团队成员协作完成开发工作，而依托开源社区能够更容易地产出优秀产品。
因此，项目最终选择基于开源产品进行二次开发。
目前所使用的Service Mesh架构设计，也被称为“渐进性”架构，主要有三个方面的特点。
• 开源方面：选择Istio和Envoy作为Service Mesh的基础设施。
• 实例和配置同步方面：由新开发的SOA Operator负责将存储在注册中心和配置中心中的数据写入K8S。
同时，该程序也会把K8S集群内服务提供方的数据写入注册中心，使得K8S集群外用户也能够正常读取服务数据。并且，该服务不需要SDK支持，由SOA Operator直接完成注册和发现，任何语言都可以方便地接入微服务产品体系。
• 使用方面：K8S集群外的应用仍然使用过去的交互方式，通过SDK和注册中心进行通信。
K8S集群内的应用，如果使用SDK，检测到Sidecar存在之后，SDK会自动地关闭服务治理功能，使用特殊的host进行请求。如果不存在SDK支持，接入Mesh可以直接使用HTTP Client，继续使用特殊的host发起请求。
更多精彩内容，欢迎观看：
《云计算加速开源创新》——基于开源体系的云原生微服务治理实践与探索（下）：https://developer.aliyun.com/article/1223962?groupCode=tech_library
