【中台架构原则是新旧融合，用中台包容传统核心】国泰靠微服务中台创造碎片化保险

出外露营会遇上哪些风险？意外受伤、旅程突然取消、露营设备因火灾意外烧毁、造成他人财物损失。这些，都是露营情境中可能会发生的风险。在国泰产险新推出的电商式投保平台BeSafe享出门，不仅将这些风险的保障内容，像是人身保障、行程保障、露营设备保障、个人责任保障的保障项目，以客制化、套餐式的方式组合。

如果露营时也带上自家宠物出门共游，心爱的宠物却发生意外而受伤，或是重要财物如手机、证件、现金失窃，甚至自己不小心将车钥匙遗失，或发生车子在路上临时抛锚，而需要多付一笔拖吊费用的状况。消费者还可在平台上自行加购商品，像是宠物保障、财物保障、汽车保障等。

这样全新的保险商业模式，只是国泰产险的BeSafe平台其中一款套餐组合。国泰产险更以出门可能会遇上的风险出发，搭配更多异质的保险险种，针对不同族群，如通勤族、银发族，打造不同的保险套餐。　

为了要能实现弹性组合、短天期保障的保险创新模式，国泰金控数位数据暨科技发展中心（简称数数发中心）与国泰产险IT团队共同合作，打造了保险中台新架构。

除了要整合现有国泰产险核心系统，又能在中台支持碎片化的保险商品快速重组，进而提供数位通路所需的弹性，目的是为了能弹性反应不同保险情境的顾客需求变化。

然而．国泰产险以往的商品逻辑设计方式，并无碎片化、短天期的概念，所以，当要导入一些新型态商品，或是需要异业合作时，通常得花上3个月到半年的时间才能上线。

因此，“如何让国泰产险的产品更具灵活性，是推出电商式投保平台的初衷。”国泰产险资讯系统开发部协理陈信良提到。

“打造碎片化车险平台有两大主轴，一是需要弹性化的中台架构，让产险可以快速发展通路；二是针对产险的核心后台，进行保险产品碎片化。”国泰金控数数发中心首席架构师张维仁指出。

这是国泰第二次中台架构大改造的成果。

第一次是设计国泰世华银行的中台，采用微服务（Microservices）架构和容器化（Container）技术、Kubernetes（K8s）管理平台，在传统银行资讯架构中，带进了中台设计的作法，后来更发展出了数据中台和业务中台。

顺利完成了银行技术中台设计后，国泰将银行架构改造经验，变成了一套架构改造范本带到了金控，进一步套用到产险领域，也就是保险中台新架构，碎片化车险专案就是第一个业务场景的应用成果。

国泰将银行架构改造经验，变成了一套架构改造范本，带到了金控，进一步套用到产险领域，也就是保险中台新架构，碎片化车险专案就是第一个业务场景的应用成果。（图片来源／国泰金控）

碎片化车险导入七大新技术架构

国泰采用了七大新技术架构来打造碎片化保险中台，包括了微服务、容器化服务、开发维运一体化（DevOps）、云端运算、事件驱动架构（Event Driven Architecture，EDA）、领域驱动设计（Domain Driven Design，DDD），以及现代化网页架构（Modernized Web）。

国泰将产险端从以往单体式且复杂的系统，拆分为多个微服务，让每支服务都可重复使用并弹性组合成新应用。

国泰金控数数发中心企业架构师高华志提到，国泰在BeSafe系统建置了业务中台，开发约700多支API，可弹性组成所需的软件服务，以支援日益复杂的客户服务管道。

在采用容器化服务部分，国泰在BeSafe系统建置了技术中台，采用K8s为基底的管理平台，让系统的扩充更有弹性。并透过技术中台集中化的系统监控机制，包含微服务日志集中、微服务效能监控，以及系统效能监控，来强化平台的稳定性。

陈信良则表示：“在异业合作上，透过API服务，从洽谈到服务上线，从原本的6个月，缩短到了1个月。”

能做到比以往更快的速度，其中还有一个关键是团队带入了敏捷式开发，陈信良提到，当前端在洽谈业务时，中台、后台核心也平行执行工作。所以，当业务需求一谈完，后台的商品设计，以及需对应到的API程式或中台服务都可同时到位，就能往下一阶段准备测试与验收。

克服产险内部人员对新技术的疑虑

然而，在这碎片化车险专案，即便有了金控端技术的支持，陈信良坦言，国泰产险在这过程中仍面临不少挑战，像是内部人员对于新架构或技术如中台、微服务等不熟悉，在心态上也对新技术抱有疑虑。“这是国泰产险转换时，最需要克服的部分。”

为了克服这些障碍，国泰金控在导入新中台架构的时候，先带着产险人员实作，透过小成果的验证，来让内部人员逐渐接受。

比如，产险IT人员在核心系统改一支程式，从开发、测试到上线，过去可能需要2天时间，透过导入DevOps机制，现在2个小时就可以完成。

“这改变让大家突然觉得有感，从原本的不相信变成怀疑，进而将小成果的案例分享给其他成员，认为这是一条正确的路，慢慢也有其他IT人员自愿参与专案，想要学习新事物。”陈信良坦言。甚至，之后国泰产险内部更透过轮替、教育训练的方式，让每个人都可以达到同样的层次。

在碎片化车险专案，国泰也持续导入DevOps机制，使用了CI/CD Pipeline将程式开发、测试与上线，透过自动化与可视化的方式快速部署，降低人工部署操作错误，且在部署时不会造成系统的停机维护。也使用自动化测试进行系统回归测试，加强整体系统问题扫描机制，并确认系统服务品质（QA）无虞。

此外，国泰团队采用了Git的程式版本控管，可透过标签（Tag）的标注方式，锁定多专案时的特定版次，弹性的合并与上线。以及，透过协同工具如Jira、Trello、Jitsi等，来强化来自金控、产险、协力厂商共50人以上的专案成员，在跨场域与居家办公的同步协作与沟通。

拔对服务是上天堂，拔错服务是灾难

“拔对服务是上天堂，拔错服务上中台是灾难。”张维仁认为，微服务中台不是只有技术中台，很大的比例是要将业务逻辑放进去。所以，如何正确将服务从传统核心当中抽离出来，介接到中台，国泰所采用的方法论就是DDD。

张维仁回忆，在2018年，国泰在第一次银行新中台架构建置时，以技术中台为主，当时还没有发展出业务中台的设计，也还没有碰触到非用DDD不可的后台议题。

所以，“国泰真正尝试、突破，导入DDD的第一个实际专案就是车险，而且范围不只中台，还跨到了后台。”他更强调，传统大核心如何在新中台架构，找出最大的相容性，谁也没有替换掉谁，且能合作顺畅的关键，就是DDD。

在专案初期，高华志指出，国泰进行DDD工作坊，将领域驱动设计的概念融入系统开发，借此让开发人员与规划人员有共同的领域语言，并能沟通顺畅。针对开发700多支微服务，则透过DDD的领域区分，进行权责的划分，且设计出好维护、好理解且容易被业务调用的程式设计架构。

碎片化保险的第一个挑战是如何“拆解”后端核心系统的业务，另一挑战则是考量如何“组合”。国泰产险资讯系统开发部同仁透露，一开始，他们其实面临了不知道要将哪些服务搬上中台的状况，在国泰这次的经验当中，最后得出了2个面向来拆解。

第一个面向是由上而下，从通路端需求，或是客户端需求来思考；第二个面向则是由下往上，从产险的数据库，也就是数据资料中找出可以价值化的服务，或是从现有流程，抽取出可以共用的服务出来。透过这4种方式，拆解出哪些需要微服务化放上中台的服务。

决定哪些服务要拆出来搬上中台之后，下一个挑战是颗粒度，要将服务切得多粗、多细？切太粗会像是一个大单体，切太细的话管理成本负担会很重。

国泰产险资讯系统开发部同仁认为，这在DDD中，其实没有一个指引或标准，得要每家公司或团队各自认定。张维仁则建议：“正确地拆解微服务，设定出微服务的边界，可以找出一个相对合理的颗粒度尺寸。

国泰将产险商品库从核心拆解细化，再由中台组合成保险套餐

若以业务层面来看微服务“拆解”与“组合”。张维仁表示，传统核心是标准的商品库、有商品代码，所以，当要推出一款保险产品时，过去的流程是将商品代码拉出来，打包成一包送主管机关审核、同意、上架。

现在的碎片化保险，张维仁比喻，像是把一台车拆成许多部件，得把既有的商品库从核心端细化搬上中台，这时，就能由中台来组合保险套餐。

由于每个商品仍有各自的商品代码，所以，在中台成立订单后，再送到核心系统做保单立案、承保，仍可依照商品代码对应到同一商品。

“碎片化产险核心这块做完，就能将弹性化组合这逻辑放在中台，产生出碎片化车险，快速组装车险灵活性套餐。”张维仁说。

高华志进一步提到，套餐之所以在中台组合，是因为保险商品碎片化后，顾客其实看不懂这些单一商品，也不知道如何挑选。所以，必须依照顾客食、衣、住、行、育、乐等生活场景，找出跟这些情境有关的风险，并组合成各式套餐供顾客选择。

以保险商品来看，陈信良更举例，国泰产险有一款专卖给餐饮业老板的综合保险产品，其中可能包含了商业火灾保险、公共意外责任险等，所以得买不只一张保单，才能满足需求。

以前，要打包多个不同的险种，得修改核心系统程式，开发工作非常的复杂。然而，现在不用每次修改核心，让顾客也能在同一平台中，就能自行挑选不同类型保险商品或是套餐组合。

以往，一张保单要算完保费、成本、核保项目、通算规则等，才有办法对外贩售。陈信良表示，整个流程碎片化后，变成好几支微服务放到中台，就能等顾客挑选完商品，甚至团队也将投保的时序拆开，让顾客有短天期投保的选择，再透过微服务化后的试算功能计算保费，就连在电商式投保平台的购物车功能，本身也是一个服务。最后，在中台成立订单后，再送到核心系统做保单立案、承保。

国泰提到，为了推出这个BeSafe平台，他们将商品库所有关于出门、出游的险种资讯全部也放到中台上来组合，才能打破先例，透过组合的方式，可在同一保单上，一次购足部分车险、旅游险、宠物保险、手机保险等。

虽然在业务组合的复杂性上，确实会增加核心的复杂性，比如以前负责车险的程式，原本只要专心做好车险。现在，因为混合了不同险种，除了车险，还可能要开发部分旅游、火险的功能。不过，陈信良表示，这些都是透过系统自动化对接并执行，对于后台作帐、承保的人员来说，作业没有增加。

从整体上来看，张维仁则强调：“在这碎片化保险专案场景中，中台与后台在逻辑上、交易上、合作上要建立机制，让新中台能够包容传统后台，并沟通无阻。既可以让中台发展通路无止尽的要求，又能让核心系统，可以回归基本面的账务功能，专注于后台处理的角色。”

由国泰金控数数发中心（照片右半部）与国泰产险IT团队（左半部）共同合作，打造了保险中台新架构，将保险商品碎片化，在国泰产险新推出的电商式投保平台BeSafe，实现弹性组合、短天期保障的保险创新模式。（摄影／洪政伟）

导入多种机制，强化量大交易的稳定与完整

为了强化量大交易的稳定与完整，高华志进一步说明，国泰在中台导入微服务时，采用了Sprint Boot框架，并加入Spring Cloud OpenFeign框架的熔断（Circuit Breaker）、重试（Retry）、负载均衡（Load Balancing）等机制。

他进一步解释，熔断机制是在瞬间量大时控制用量，以确保服务能持续提供；负载均衡的机制，则是要达到分时多工或是同时多工的方式；重试机制则是在中台的订单要转为后台的保单时，来确保两边的交易能完整一致。

此外，国泰在事件驱动架构上，采用Kafka设计架构，运用在中台系统与核心系统的资讯串接与任务编排，目的是让内部间跨系统资讯串接能更加即时与稳定。

而为了要让中台与后台跨系统资讯串接时，也就是中台成立订单之后，串接到后台核心系统时，确保两边的订单笔数一致。高华志提到，他们还自行开发了巡检机制（Patrolling Mechanism）。当核心系统执行时出现异常的状况，可以自动化确认问题，通知人工介入处理，判断是否需要进行重试的动作。

张维仁强调：“得确保中台所处理的交易量，跟后台核心正确接收到的交易量是对等的。只要一失焦，整个机制就毁了。”

他透露，国泰其实也曾担忧，一旦中台介入之后，会与后台产生交易断层，或者是后台可能因为短时间内处理量过多或者是其他因素，导致交易笔数不正确时，就需要有检核的机制。甚至，即便跨系统资料串接之间有异常发生时，也要能有平衡机制，即时修复成一致。“这些是中台串接后台，一定跑不掉的话题。”他强调。

使用防腐层作为中台介接后台的中间层，确保核心不受影响

国泰在这次的碎片化保险专案的设计概念，围绕在新中台架构的乘载量或新东西，不要影响到既有核心心脏的功能。所以，一名国泰产险资讯系统开发部同仁表示，尽量避免中台与后台的关联度过高，以免造成同时毁掉的状况。

因此，在中台系统与后台系统对接时，国泰使用了防腐层（Anti Corruption Layer）的设计概念，用这中间层来区隔中台与后台。一旦中台有瞬间爆量的状况发生，比如举办各式行销活动时，就只会影响到中台跟中间层，并不会影响到后台。反之亦然，如果后台有问题发生，也只会影响中间层，而不会影响到中台。

国泰解释，防腐层又分为两种模式，一种是异步式，系统允许中间有短暂时间可以执行。例如用伫列，当遇到爆量状况时，后台会依照运算资源，依序一笔一笔处理。

另一种是同步式，有些业务需要后台系统即时确认的，比如需要即时通算保额不能过量的部分，就会在后台另外建立API服务器作为防腐层。同样的，一旦这个API服务器出问题，也不会影响后台功能。

陈信良表示，透过同步、异步机制，可以把中台、后台两边串连的很稳定，核心系统也不用大量修改，因为前端所有进件以及内勤打单的部分，流程跟以往是一模一样。“核心系统人员不用因为前端变化，而调整新的流程。”他强调。

有了碎片化车险的第一个成功案例，陈信良指出，产险端只要是交易频繁或是业务量多，需要大量承载的，包括来自客户需求的产品，就交由前台满足，让后台维持稳定运行，这是国泰产险接下来的规划。