才云助保险巨头基于服务网格进行微服务敏捷业务创新

本篇文章3322字，读完约8分钟

随着数字和信息技术的不断发展，越来越多的中国保险公司正试图利用数字技术来提高保险业的风险控制、精算和服务水平，加快数字战略的发展，并赋予保险业技术创新自身业务的能力。 本文的主角是一家国内上市保险公司，作为一家国有超大型金融保险公司，连续17年入选《财富》全球500强。自2017年以来，企业先后完成了内部应用和外部业务应用的云原生转换和迁移，并开始从客户体验、业务运营和业务模式三个方面全面实施数字化战略。

随着云业务数量的增加，为了更灵活、更敏捷地应对业务变化，降低企业it架构设计的难度，企业在蔡赟科技的帮助下，将其核心业务系统架构从soa架构转变为以微服务为代表的分散分布式软件架构，并通过数字转型优化客户体验。

核心困难:业务系统架构尴尬且不堪重负

作为金融领域的核心产业之一，保险业一直深受同质化的困扰。近年来，随着互联网在保险业的全面渗透，虽然大量保险公司通过互联网渠道快速、低成本地联系了大量客户，但由于产品替代性强、缺乏核心竞争力，仍无法避免被迫陷入价格竞争的恶性循环。

为了使业务走出瓶颈，更快地适应市场变化，许多保险公司开始通过数字化转型推出更多的场景产品和定制产品。在这个过程中，敏捷开发和自动化运维带来的效率提升和成本降低备受关注:谁的流程更敏捷，能更快地响应市场，同时服务质量更有保障，他的核心竞争力必然更强。

蔡云的客户是中国最大的寿险公司，在国内保险市场一直占据领先地位。在2018年内部业务形势分析会上，公司将客户体验数字化、运营管理数字化、业务模式数字化、数字基础平台综合整合作为未来数字转型的“四大举措”。

随着数字业务的发展，业务系统和服务项目的增加，客户原有的soa架构开始暴露出以下四大问题，威胁到业务敏捷性和客户体验:

Esb成为瓶颈

在soa架构中，所有业务系统服务都依赖esb(企业服务总线)进行交互和数据传输。然而，这种设计不能适应当前数字商务的发展。例如，在电子商务的大力推广和旅游旺季，会产生大量的小额和高频保险交易和索赔。面对如此激增的流量，服务和业务系统之间的调度容易出现问题，esb成为业务扩展的性能瓶颈。

同时，esb将成为一个明显的单点故障，每一次esb故障都会导致所有业务系统的故障。如果企业想在不改变架构的情况下解决上述两个问题，他们需要投入大量成本来扩展esb。

服务治理不够灵活

目前，企业在所有业务发布流程中都引入了灰度发布流程，这主要依赖于前一阶段的负载均衡设备，因此灰度发布的灵活性和复杂性有一定的局限性。

受负载均衡器成本的限制，企业无法对所有服务进行精细的流量管理，只能在负载均衡后端安装重要的外部服务和系统服务。当不同的业务系统之间存在调用权限的设计时，或者有多个版本的业务系统内部服务同时服务时，工程师需要通过业务代码手动实现，这高度依赖于人力。

系统维护和更新很困难

操作和维护困难以及对开发人员技术栈的高要求是soa架构的常见缺点。随着业务系统的数量和复杂性的增加，企业的系统操作和维护人员的压力也逐渐增加。

在业务异常或系统故障的情况下，运维人员需要花费大量的精力来确认系统调用逻辑和整理业务请求。为了避免单一服务异常导致的业务系统雪崩，软件开发人员在系统设计过程中还需要考虑保险丝、限流等功能，这无形中增加了系统开发的难度，延长了系统更新周期。

业务极难排除故障

在业务运营和维护方面，该企业作为保险业的龙头企业，已经实现了对终端用户的网上保险、申报、承保和支付功能，审计部门需要定期对业务进行审计。

当一个事务需要重新关闭时，工作人员需要从大量的系统日志中找到相关的内容，这需要很长时间，而且效率很低。当发现在线业务异常时，由于采用了soa架构，业务运营和维护人员无法及时得到相关事务请求的细节，响应不够及时。

客户需求:企业特色的定制化发展

除了上述需求和挑战，企业本身也有许多需要额外关注的特征。

首先，就业务系统的资源形式而言，企业在2018年完成了部分生产系统的集装箱化改造，因此仍有大量未改造的虚拟机和物理机形式的应用，这意味着在技术框架设计和技术方案选择过程中，蔡赟团队需要考虑大量混合资源的存在。

在系统改造过程中，考虑到开发人员和运维人员不同的技术背景和工作重点，企业希望不要引入太多额外的技术栈和工具，以免带来新的技术负担和风险。

系统改造后，后台用户包括系统管理员、系统运维人员和业务运维人员。大多数用户在系统底层没有访问权限，也不一定具备命令行和api操作能力，因此整个系统的访问权限管理需要相应地设计。同时，蔡赟团队还需要以图形界面的形式展示所有的操作和演示，这样使用起来很方便。

人才云解决方案:服务网格控制台

基于上述困难，企业意识到，与传统的soa架构相比，细粒度的服务拆分和分散的微服务架构设计更适合当前市场对敏捷开发和快速迭代的需求。然而，在微服务架构中存在服务治理问题。为了使其适用于生产环境，建立服务网格控制台迫在眉睫。

作为一家技术实力得到业界深度认可的智能集装箱云平台和ai服务提供商，蔡赟在金融行业的系统架构、服务治理和devops方面积累了丰富的经验和实战能力，因此此次也被企业选为构建服务网格控制台的解决方案提供商。

基于上述难点和定制需求，蔡赟团队和企业共同设计并实施了以下服务网格技术解决方案:

该方案实现了域和业务系统的服务网格能力。

分散分布式软件体系结构

针对soa架构中企业服务总线的单点问题，蔡赟对原有的客户技术架构进行了微服务改造，通过服务网格避免了单一中心点的出现。

使用服务网格管理控制台后，尽管所有服务仍然需要在服务注册中心注册才能发现，但是服务之间的服务调用现在可以通过数据平面中的sidecar进行转发，sidecar连接到每个服务，因此服务之间的调用模式已经从中央间接调用变为分布式直接调用。业务系统的能力不再受esb的限制，任何一个系统或服务的异常都不会影响其他服务或系统。

完善的服务治理

针对负载均衡和流量管理的困难，蔡赟在解决方案中使用服务网格实现了精细化服务治理。

通过服务网格管理控制台，管理员可以在控制平台上发布各种策略，实现多种服务版本共存下的精细化呼叫管理，让不同来源的请求发送到目标版本的侧车，并根据请求来源和内容的特点实现权限和速率的管理和控制。

降低操作和维护难度

服务网格管理控制台下的系统拓扑集合可以称为操作和维护人员的福利。通过它，整个业务系统中各个服务的调用关系变得更加直观和易于观察，极大地方便了操作和维护人员在系统出现异常时进行故障排除。

同时，分布式跟踪还可以显示当前服务的具体请求，为系统扩展和性能提升提供相关的数据依赖。

自动日志收集

为了帮助审计部门更方便地对业务进行审计，并为业务部门汇总数据提供方便，服务网格管理控制台还提供了自动应用日志和消息收集功能。

Sidecar将收集系统底部的请求日志和会话内容，然后将它们报告给服务网格控制平面，并根据实际的业务逻辑统一组织内容，以便不同技术背景的工作人员直观地查看相关请求的具体内容和处理情况。

深度技术服务

服务网格管理控制台交付后，为了帮助客户适应新的分布式系统架构，回答各种技术和专业问题，蔡赟团队不仅提供人员常驻服务，还对整体框架进行基准性能测试和压力测试，并对特使服务治理配置进行独家深入分析(见此处)，并推出世界上第一个中文版的ratelimit(见此处)，方便更多国内企业和工程师从蔡赟和客户的服务网格成功实践。

摘要

随着整体架构设计的完成和系统开发的进展，企业已经将一些应用系统迁移到了服务网格中，这些服务的观察、管理和运行维护都得到了很大的改善，系统成熟和功能丰富的优势也得到了很大的展示。

目前，服务网格管理控制台覆盖并解决了异构资源环境下的流量调度、管理、观察和跟踪。随着后续服务的发展和日益增多，它可以通过分散的分布式架构完美地支持业务系统的扩展，帮助客户面对业务灵活性给系统带来的挑战，减少运维人员的工作量，减少在线故障。

根据目前的规划安排，企业已将所有应用系统纳入迁移议程。在所有迁移之后，服务网格控制台将承载近100个系统和数千个重要服务！

来源：央视线