保险IT微服务架构培训课件PPT实用课件(共40页)
合集下载
保险基础知识培训讲课PPT课件
目录
CONTENTS
01
单击输入您的文字
ENTER TEXT
02
单击输入您的文字
ENTER TEXT
书房的角落，挺立着一株虎尾兰。它 没有牡 丹的高 贵，没 有百合 花的幽 香，更 没有玫 瑰花那 样高傲 ，它除 了平凡 ，还是 平凡。 以至于 客人来 访，也 无一夸 赞过它 ，更没 有谁欣 赏它。
书房的角落，挺立着一株虎尾兰。它 没有牡 丹的高 贵，没 有百合 花的幽 香，更 没有玫 瑰花那 样高傲 ，它除 了平凡 ，还是 平凡。 以至于 客人来 访，也 无一夸 赞过它 ，更没 有谁欣 赏它。
书房的角落，挺立着一株虎尾兰。它 没有牡 丹的高 贵，没 有百合 花的幽 香，更 没有玫 瑰花那 样高傲 ，它除 了平凡 ，还是 平凡。 以至于 客人来 访，也 无一夸 赞过它 ，更没 有谁欣 赏它。
书房的角落，挺立着一株虎尾兰。它 没有牡 丹的高 贵，没 有百合 花的幽 香，更 没有玫 瑰花那 样高傲 ，它除 了平凡 ，还是 平凡。 以至于 客人来 访，也 无一夸 赞过它 ，更没 有谁欣 赏它。
书房的角落，挺立着一株虎尾兰。它 没有牡 丹的高 贵，没 有百合 花的幽 香，更 没有玫 瑰花那 样高傲 ，它除 了平凡 ，还是 平凡。 以至于 客人来 访，也 无一夸 赞过它 ，更没 有谁欣 赏它。
书房的角落，挺立着一株虎尾兰。它 没有牡 丹的高 贵，没 有百合 花的幽 香，更 没有玫 瑰花那 样高傲 ，它除 了平凡 ，还是 平凡。 以至于 客人来 访，也 无一夸 赞过它 ，更没 有谁欣 赏它。
01
02
书房的角落，挺立着一株虎尾兰。它 没有牡 丹的高 贵，没 有百合 花的幽 香，更 没有玫 瑰花那 样高傲 ，它除 了平凡 ，还是 平凡。 以至于 客人来 访，也 无一夸 赞过它 ，更没 有谁欣 赏它。
微服务理论与实践培训课件PPT(共 36张)
改和发布。 ❖ 避免破坏性修改 服务的修改不能导致该服务的消费方发生
改变。 ❖ 保证API与技术的无关性 ❖ 保证API的易用性 ❖ 隐藏内部实现细节
12
h
微服务集成
❖ 2、编排与协同 ❖ 编排：同步调用一组服务，等待各个服务的返回结果。优
点是知道业务流程中每一步跨服务调用结果，缺点是容易 承担太多的调用，太耗时，导致调用方的不稳定性。
❖ 因此演变成右图这样，左图只需提供服务接口给右图调用 即可。
28
h
案例分析
❖ 案例三：服务设计中的不良习惯
29
h
案例二：如何跨系统访问数据表
❖ 在此系统中，ABCD四个系统进行了串联，这样就要求这 四个系统分别都是高可用的，如果其中任何一个系统挂了 或者发生问题，都会直接影响其他所有系统。
❖ 所以设计微服务架构的时候要尽量避免这种集中式的架构。
communicating with lightweight
mechanisms, often an HTTP resource API.
These services are built around business
capabilities and independently deployable
服务都可以单独修改和布署。 ❖ 高内聚：把相关的事务放在一起，把不相关的排除出去，
聚集在一起的事务只能干同一件事。
8
h
微服务的建模
❖ 2、限界上下文 ❖ 限界：划分规定界限、边界 ❖ 上下文：业务的整会发现系统中存在混杂 在一起的模型，模型之间的边界是非常模糊的。此时应 该为整个系统绘制一个边界，然后将其归纳在大范围之 内。
和分区容忍性。这个定理告之我们最多只能能保证三个中 的两个。
改变。 ❖ 保证API与技术的无关性 ❖ 保证API的易用性 ❖ 隐藏内部实现细节
12
h
微服务集成
❖ 2、编排与协同 ❖ 编排：同步调用一组服务，等待各个服务的返回结果。优
点是知道业务流程中每一步跨服务调用结果，缺点是容易 承担太多的调用，太耗时，导致调用方的不稳定性。
❖ 因此演变成右图这样，左图只需提供服务接口给右图调用 即可。
28
h
案例分析
❖ 案例三：服务设计中的不良习惯
29
h
案例二：如何跨系统访问数据表
❖ 在此系统中，ABCD四个系统进行了串联，这样就要求这 四个系统分别都是高可用的，如果其中任何一个系统挂了 或者发生问题，都会直接影响其他所有系统。
❖ 所以设计微服务架构的时候要尽量避免这种集中式的架构。
communicating with lightweight
mechanisms, often an HTTP resource API.
These services are built around business
capabilities and independently deployable
服务都可以单独修改和布署。 ❖ 高内聚：把相关的事务放在一起，把不相关的排除出去，
聚集在一起的事务只能干同一件事。
8
h
微服务的建模
❖ 2、限界上下文 ❖ 限界：划分规定界限、边界 ❖ 上下文：业务的整会发现系统中存在混杂 在一起的模型，模型之间的边界是非常模糊的。此时应 该为整个系统绘制一个边界，然后将其归纳在大范围之 内。
和分区容忍性。这个定理告之我们最多只能能保证三个中 的两个。
金融机构财产保险公司IT信息系统知识培训l课件(22P)
◆预付：前置条件：在立案之后，全部核损完成前，可以进行预付操作。 ◆追偿案件：
再保险概念
再保险（reinsurance）亦称分保：是保险人在原保险合同的基本上，通过签订 分保合同，将其所承保的部分风险和责任向其他保险人进行保险的行为。 原保险合同：是投保人与保险人之间签订的，以保障双方利益的合同。 再保险合同：是分出公司与分入公司之间签订的，以保障双方利益的合同。 原保险人：在再保险交易中，分出业务的公司称为原保险人（original insurer）， 或分出公司（ceding company）。 再保险人：接受业务的公司称为再保险人，或分保接受人或分入公司（ceded company）。 分保手续费：又称分保佣金，由分入公司支付给分出公司的，用以补偿分出公司 的招揽业务过程中支出的部分费用报酬。 盈余佣金又称为利润手续费：再保险人获得赢利时，按合同规定从中提一定比例 的盈余佣金作为支付原保险人的报酬或奖励。 危险单位：是指保险标的发生一次灾害事故可能造成的最大损失范围。 自留额：分出公司根据自身偿付能力所能确定承担的责任限额，称为自留额或自 负责任额。 分保额：又称分保责任额或接受额，是指经过分保由接受公司所承担的责任限额。
公司的信息系统概况
整车零配件 影像
费控系统 反洗钱
核心
销售管理
再保
单
车承保
非车承保
证
收
付
车理赔
非车理赔
OA
外网自主查 询
非现场稽核
资金系统
财务总账 EBS
偿付能力 网银系统 准备金系统 统计上报
短信平台 数据仓库
车险平台 CRM
网销 呼叫中心
新销管
偿付二代风 控
HR 预算系统
核心系统
再保险概念
再保险（reinsurance）亦称分保：是保险人在原保险合同的基本上，通过签订 分保合同，将其所承保的部分风险和责任向其他保险人进行保险的行为。 原保险合同：是投保人与保险人之间签订的，以保障双方利益的合同。 再保险合同：是分出公司与分入公司之间签订的，以保障双方利益的合同。 原保险人：在再保险交易中，分出业务的公司称为原保险人（original insurer）， 或分出公司（ceding company）。 再保险人：接受业务的公司称为再保险人，或分保接受人或分入公司（ceded company）。 分保手续费：又称分保佣金，由分入公司支付给分出公司的，用以补偿分出公司 的招揽业务过程中支出的部分费用报酬。 盈余佣金又称为利润手续费：再保险人获得赢利时，按合同规定从中提一定比例 的盈余佣金作为支付原保险人的报酬或奖励。 危险单位：是指保险标的发生一次灾害事故可能造成的最大损失范围。 自留额：分出公司根据自身偿付能力所能确定承担的责任限额，称为自留额或自 负责任额。 分保额：又称分保责任额或接受额，是指经过分保由接受公司所承担的责任限额。
公司的信息系统概况
整车零配件 影像
费控系统 反洗钱
核心
销售管理
再保
单
车承保
非车承保
证
收
付
车理赔
非车理赔
OA
外网自主查 询
非现场稽核
资金系统
财务总账 EBS
偿付能力 网银系统 准备金系统 统计上报
短信平台 数据仓库
车险平台 CRM
网销 呼叫中心
新销管
偿付二代风 控
HR 预算系统
核心系统
微服务架构 ppt课件
Microservice
The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
在变得越来越大的同时，我们的应用所使用的技术 也会变得越来越多。这些技术有些是不兼容的，就 比如在一个项目中大范围地混合使用C++和Java几 乎是不可能的事情。在这种情况下，我们就需要抛 弃对某些不兼容技术的使用，而选择一种不是那么 适合的技术来实现特定的功能。
除此之外，由于按照Monolith组织的代码将只产生 一个包含了所有功能的WAR包，因此在对服务的 容量进行扩展的时候，我们只能选择重复地部署这 些WAR包来扩展服务能力，而不是仅仅扩展出现 系统瓶颈的组成
2024版微服务架构在软件开发中的应用培训课件
镜像管理
通过容器镜像仓库对微服务镜像进行统一存储和 管理，确保镜像的安全性和一致性。
3
容器网络
配置容器网络，实现微服务之间的通信和负载均 衡。
监控、日志与故障排查
监控策略
01
制定微服务监控策略，包括性能指标、业务指标和异常指标等
，及时发现潜在问题。
日志收集与分析
02
配置日志收集工具，对微服务日志进行统一收集、存储和分析
使用Redis等分布式缓存 技术，实现数据的共享和 高速访问。
横向扩展与纵向扩展对比
横向扩展
通过增加服务器数量来提高系统处理能力，易于实现且成本较低 。
纵向扩展
通过提升单台服务器的性能来提高系统处理能力，成本较高且存 在单点故障风险。
对比总结
横向扩展更具灵活性和可扩展性，适合大型分布式系统；纵向扩 展适用于小型系统或对性能要求不高的场景。
微服务架构在软件开发中的
04
应用实践
需求分析与设计
确定微服务边界
根据业务领域和功能需求，将系 统拆分为独立的、可独立部署的 微服务，每个微服务负责特定的
业务功能。
定义服务接口
设计清晰、简洁的服务接口，包括 输入、输出参数和错误处理机制， 确保微服务之间的通信顺畅。
数据一致性考虑
在微服务架构中，数据一致性是一 个重要问题。需要合理设计数据库 事务、分布式锁等机制，确保数据 的完整性和一致性。
开发环境与工具选择
容器化技术
微服务框架
使用Docker等容器化技术，实现微服 务的快速部署和隔离，提高开发效率 和系统稳定性。
选择适合的微服务框架，如Spring Cloud、Dubbo等，简化微服务开发 过程，提供负载均衡、服务注册与发 现等功能。
通过容器镜像仓库对微服务镜像进行统一存储和 管理，确保镜像的安全性和一致性。
3
容器网络
配置容器网络，实现微服务之间的通信和负载均 衡。
监控、日志与故障排查
监控策略
01
制定微服务监控策略，包括性能指标、业务指标和异常指标等
，及时发现潜在问题。
日志收集与分析
02
配置日志收集工具，对微服务日志进行统一收集、存储和分析
使用Redis等分布式缓存 技术，实现数据的共享和 高速访问。
横向扩展与纵向扩展对比
横向扩展
通过增加服务器数量来提高系统处理能力，易于实现且成本较低 。
纵向扩展
通过提升单台服务器的性能来提高系统处理能力，成本较高且存 在单点故障风险。
对比总结
横向扩展更具灵活性和可扩展性，适合大型分布式系统；纵向扩 展适用于小型系统或对性能要求不高的场景。
微服务架构在软件开发中的
04
应用实践
需求分析与设计
确定微服务边界
根据业务领域和功能需求，将系 统拆分为独立的、可独立部署的 微服务，每个微服务负责特定的
业务功能。
定义服务接口
设计清晰、简洁的服务接口，包括 输入、输出参数和错误处理机制， 确保微服务之间的通信顺畅。
数据一致性考虑
在微服务架构中，数据一致性是一 个重要问题。需要合理设计数据库 事务、分布式锁等机制，确保数据 的完整性和一致性。
开发环境与工具选择
容器化技术
微服务框架
使用Docker等容器化技术，实现微服 务的快速部署和隔离，提高开发效率 和系统稳定性。
选择适合的微服务框架，如Spring Cloud、Dubbo等，简化微服务开发 过程，提供负载均衡、服务注册与发 现等功能。
保险IT数字化转型培训课件(ppt 36张)
保险IT 数字化转型
Elvis Zhang 2016年10月
大数据正带来保险产品、作业、组织、监管模式的改变。在大数据的支撑下，风险可 以更精细划分，保险作业更深更广融地入具体场景，即所谓场景保险。
保险产品可以更加碎片化；保险公司采取更多甚至全部在线的作业流程，即所谓保 险的O2O；保险公司内部完整作业链条的围墙被拆除、打碎后重新组装。
随着“互联网+”向着“移动化、专业化、社交化、场景化”深入发展，服务与体验将 成为市场竞争的关键。通过“服务”而不是“销售”，保险才能深入到更多用户（先用 户再客户）的生活，才能真正“连接一切”。
从传统的保险公司发展历程看，现在遇到最大的问题不是技术，最大的问题其实是它的客户 群发生了改变。客户的期望也正在发生根本性的变化：简单、便捷、透明、个性化以及社交 化。
选择了微服务架构也就意味着选择了一个开放、自由、大型的技术应用平台。微服务架构能 在任何操作系统和硬件配置上运行，现有的操作系统和硬件能被保留使用； 微服务架构可以 将通用的繁琐的服务端任务交给中间件完成，这样开发人员可以集中精力在如何创建商业逻 辑上，相应缩短开发时间。
目前保险企业各个业务系统存在较多应用竖井，每个竖井都需要通过专有的接口提供各自的 服务。依据业务发展趋势和建设规划，需要从面向系统转型面向服务，通过服务组件提供应 用和数据；需要进行架构解耦，消除应用竖井，让业务功能以标准化的业务服务形态暴露给 最终用户，使服务可共享并重复利用。通过建立微服务架构的IT平台将信息技术与业务的有 效结合起来，从而推动企业产品创新、服务创新及市场创新。
随着保险行业新渠道、新业务的推出和发展，敏捷开放的IT架构、移动互联、大数据、商业智 能等技术对保险行业的销售、决策、管理等方面起着越来越重要的作用。
Elvis Zhang 2016年10月
大数据正带来保险产品、作业、组织、监管模式的改变。在大数据的支撑下，风险可 以更精细划分，保险作业更深更广融地入具体场景，即所谓场景保险。
保险产品可以更加碎片化；保险公司采取更多甚至全部在线的作业流程，即所谓保 险的O2O；保险公司内部完整作业链条的围墙被拆除、打碎后重新组装。
随着“互联网+”向着“移动化、专业化、社交化、场景化”深入发展，服务与体验将 成为市场竞争的关键。通过“服务”而不是“销售”，保险才能深入到更多用户（先用 户再客户）的生活，才能真正“连接一切”。
从传统的保险公司发展历程看，现在遇到最大的问题不是技术，最大的问题其实是它的客户 群发生了改变。客户的期望也正在发生根本性的变化：简单、便捷、透明、个性化以及社交 化。
选择了微服务架构也就意味着选择了一个开放、自由、大型的技术应用平台。微服务架构能 在任何操作系统和硬件配置上运行，现有的操作系统和硬件能被保留使用； 微服务架构可以 将通用的繁琐的服务端任务交给中间件完成，这样开发人员可以集中精力在如何创建商业逻 辑上，相应缩短开发时间。
目前保险企业各个业务系统存在较多应用竖井，每个竖井都需要通过专有的接口提供各自的 服务。依据业务发展趋势和建设规划，需要从面向系统转型面向服务，通过服务组件提供应 用和数据；需要进行架构解耦，消除应用竖井，让业务功能以标准化的业务服务形态暴露给 最终用户，使服务可共享并重复利用。通过建立微服务架构的IT平台将信息技术与业务的有 效结合起来，从而推动企业产品创新、服务创新及市场创新。
随着保险行业新渠道、新业务的推出和发展，敏捷开放的IT架构、移动互联、大数据、商业智 能等技术对保险行业的销售、决策、管理等方面起着越来越重要的作用。
微服务架构原理和设计方法ppt(49张)
微 服 务 架 构 原理和 设计方 法(PPT 49页) 微 服 务 架 构 原理和 设计方 法(PPT 49页)
业务架构：是把企业的业务战略转化为日常 运作的渠道，业务战略决定业务架构，它包括 业务的运营模式、流程体系、组织结构、地域 分布等内容
IT架构：指导IT投资和设计决策的IT框架， 是建立企业信息系统的综合蓝图，包括数据架 构、应用架构和技术架构三部分。
企业架构
TOGAF架构
TOGAF 由国际标准权威组织The Open Group制定。1993年开始应客户要求制定系统 架构的标准，在1995年发表 (TOGAF) 架构框 架。TOGAF的基础是美国国防部的信息管理技 术架构，是基于一个迭代的过程模型，支持最 佳实践和一套可重用的现有架构资产。它可设 计、评估、并建立组织的正确架构。
微 服 务 架 构 原理和 设计方 法(PPT 49页)
微服务与DDD
英文名字：Domain Driven Design。
中文名字：领域驱动设计。
Байду номын сангаас概 述：DDD是一种以领域为核心 的设计和开发理念。DDD通过维护一 个深度反应领域概念的模型，以及提 供了可行的经过实践检验的大量模式 来应对领域的复杂性，偏向代码实现 的（领域）对象
微 服 务 架 构 原理和 设计方 法(PPT 49页)
微 服 务 架 构 原理和 设计方 法(PPT 49页) 微 服 务 架 构 原理和 设计方 法(PPT 49页)
信息专家 创建者 高内聚 低耦合 控制者 多态 纯虚构 间接性
变化预防
微服务与GRASP基本原则
• 给对象分配职责的基本原则是什么？ • 假设系统中存在一个类A，那么在这个系统中，谁应该负责创建类A的新实例？ • 怎样保持对象是有重点的、可理解的、可管理的，并且能够支持低耦合？ • 怎样降低依赖性，减少变化带来的影响，提高重用性？ • 在UI层之上首先接收和协调（控制）系统操作的第一个对象是什么？ • 如何处理基于类型的选择？如何创建可插拔的软件构件？ • 当你并不想违背高内聚和低耦合或其他目标，但是基于专家模式所提供的方案又不合适时，哪些对象应该承担这一职责？ • 为了避免两个或多个事务之间直接耦合，应该如何分配职责？如何使对象解耦合，以支持低耦合并提高复用性潜力？ • 如何设计对象、子系统和系统，使其内部的变化或不稳定性不会对其他元素产生不良影响？
微服务架构 ppt课件
微服务架构
主讲人：xxx 组员：xxx
微服务的诞生 1
2
Monolith
CONTENTS
微服务的定义 3
微服务架构模式 4
微服务架构的优点与缺点 5 具体应用 6
微服务的诞生
微服务架构（Microservice Architect）是 一种架构模式，它提倡将单块架构的应用 划分成一组小的服务，服务之间互相协调、 互相配合，为用户提供最终价值。每个服 务运行在其独立的进程中，服务与服务间 采用轻量级的通信机制互相沟通。每个服 务都围绕着具体业务进行构建，并且能够 被独立的部署到生产环境、类生产环境等。
可以说，所有的不便都是由于Monolith服务中一个 WAR包包含了该服务的所有功能所导致的。而解 决该问题的方法就是Microservice架构模式。
微服务的定义
实际上，从业界的讨论来看,微服务本身 并没有一个严格的定义。不过， ThoughtWorks的首席科学家，马丁 -福 勒先生对微服务的这段描述，似乎更加具 体、贴切，通俗易懂：
但是这种扩展方式极 大地浪费了资源。就 以上图所展示的情况 为例：在一个服务中， 某个组成的负载已经 达到了90%，也就是 到了不得不对服务能 力进行扩容的时候了。 而同一服务的其它三 个组成的负载还没有 到其处理能力的20%。
由于Monolith服务中 的各个组成是打包在 同一个WAR包中的， 因此通过添加一个额 外的服务实例虽然可 以将需要扩容的组成 的负载降低到了45%， 但是也使得其它各组 成的利用率更为低下。
微服务架构
微服务架构是一种架构模式，它提倡将单一应用程序 划分成一组小的服务，服务之间互相协调、互相配合， 为用户提供最终价值。每个服务运行在其独立的进程 中，服务与服务间采用轻量级的通信机制互相沟通 （通常是基于HTTP协议的RESTful API）。每个服务 都围绕着具体业务进行构建，并且能够被独立的部署 到生产环境、类生产环境等。另外，应当尽量避免统 一的、集中式的服务管理机制，对具体的一个服务而 言，应根据业务上下文，选择合适的语言、工具对其 进行构建。
主讲人：xxx 组员：xxx
微服务的诞生 1
2
Monolith
CONTENTS
微服务的定义 3
微服务架构模式 4
微服务架构的优点与缺点 5 具体应用 6
微服务的诞生
微服务架构（Microservice Architect）是 一种架构模式，它提倡将单块架构的应用 划分成一组小的服务，服务之间互相协调、 互相配合，为用户提供最终价值。每个服 务运行在其独立的进程中，服务与服务间 采用轻量级的通信机制互相沟通。每个服 务都围绕着具体业务进行构建，并且能够 被独立的部署到生产环境、类生产环境等。
可以说，所有的不便都是由于Monolith服务中一个 WAR包包含了该服务的所有功能所导致的。而解 决该问题的方法就是Microservice架构模式。
微服务的定义
实际上，从业界的讨论来看,微服务本身 并没有一个严格的定义。不过， ThoughtWorks的首席科学家，马丁 -福 勒先生对微服务的这段描述，似乎更加具 体、贴切，通俗易懂：
但是这种扩展方式极 大地浪费了资源。就 以上图所展示的情况 为例：在一个服务中， 某个组成的负载已经 达到了90%，也就是 到了不得不对服务能 力进行扩容的时候了。 而同一服务的其它三 个组成的负载还没有 到其处理能力的20%。
由于Monolith服务中 的各个组成是打包在 同一个WAR包中的， 因此通过添加一个额 外的服务实例虽然可 以将需要扩容的组成 的负载降低到了45%， 但是也使得其它各组 成的利用率更为低下。
微服务架构
微服务架构是一种架构模式，它提倡将单一应用程序 划分成一组小的服务，服务之间互相协调、互相配合， 为用户提供最终价值。每个服务运行在其独立的进程 中，服务与服务间采用轻量级的通信机制互相沟通 （通常是基于HTTP协议的RESTful API）。每个服务 都围绕着具体业务进行构建，并且能够被独立的部署 到生产环境、类生产环境等。另外，应当尽量避免统 一的、集中式的服务管理机制，对具体的一个服务而 言，应根据业务上下文，选择合适的语言、工具对其 进行构建。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
本着满足客户需求，面向未来发展，结合产品营销策略、业务发展规划、业务形态和业务流程 的原则建立敏捷开放的IT平台。
微服务架构的建设策略
以客户为中心 • 建立360度客户视图 • 支持个性化和个人自助服务 • 各渠道与客户信息平台集成
场景化产品 • 提供参数化配置，缩短新产品和服务达到市场的时间 • 保障范围更加具体化，产品融入渠道业务场景 • 结合渠道的业务形态与合作伙伴的需要研发定制产品
• 洞察客户需求、满足客户期望，与 客户建立长期关系
• 实现创新的营销、无缝多渠道的销 售、实时精准的风险控制、灵活高 效的运营模式
• 优化企业价值链，促进资源跨界整 合，共建开放、共赢的产业生态系 统
• 让业务模式与产品具备高度的可配 置性与可扩展性, 快速捕捉市场机 遇
未来的业务模式不再是面向产品或者面向保单的，而应该是面向客户的，所以需要 IT平台可以提供跨企业各个系统的客户统一视图。
灵活应对变化与合作 • 支持新渠道和新合作伙伴的开发与集成 • 嵌入式营销，产品贴近用户场景需要 • 基于数据，精准营销
客户
现在
扩展
新类型
已有保单
产品
现有产品
保障的扩 展
新产品
现有渠道 现有渠道
新渠道
类型的扩展 类型
渠道
敏捷开放的IT架构
• 建立基于微服务架构的IT平台 • Scrum、敏捷开发 • DevOps、持续交付
• 通过大数据智能分析， 提升业务决策支持能力，实 时、准确的预测风险，制定贴合客户需求并有竞争力 的产品、营销和风险战略
• 业务系统可以灵活地和外部伙伴的业务系统建立集成、 合作关系，对外提供功能服务或者使用外部的服务变 得简单而灵活
• 灵活的产品建模工具、便捷的产品发布方法 紧密衔接的业务流程、灵活配置的业务规则
保险行业是我国市场经济体系的重要组成部分，随着国际化竞争地加剧，对内降低
组织的摩擦力，提升公司的运营效率；对外实现与客户更友好的沟通，提升服务水 平，对客户需求给予迅速回应成为行业亟待解决的战略问题。
在保险行业信息化发展上主要经历了三个阶段： 第一阶段是业务处理阶段，各保险公司主要实现了各自的核心业务系统； 第二阶段是业务拓展阶段，主要围绕业务拓展，渠道管理、客户服务等面进行扩展。
保险移动展业、自助理赔等逐渐成为各大险企积极发力开拓的营销与服务模式。 微服务平台利用开放式标准化的接口技术（RESTful API），可以灵活地匹配多渠道移动展业的 需要，并实现客户自助服务，把客户与企业及合作伙伴无缝连接起来。充分利用移动终端设 备的功能，提升营销效率、降低营销成本、提高服务品质。
第三阶段是经营管理和决策支持阶段，通过商业智能等技术，推动保险公司管理和决策水平的 提高。并充分对信息数据进行分析、挖掘、处理，为保险公司经营及管理提供支持。
随着保险行业新渠道、新业务的推出和发展，敏捷开放的IT架构、移动互联、大数据、商业智 能等技术对保险行业的销售、决策、管理等方面起着越来越重要的用。
随着“互联网+”向着“移动化、专业化、社交化、场景化”深入发展，服务与体验将 成为市场竞争的关键。通过“服务”而不是“销售”，保险才能深入到更多用户（先用 户再客户）的生活，才能真正“连接一切”。
从传统的保险公司发展历程看，现在遇到最大的问题不是技术，最大的问题其实是它的客户 群发生了改变。客户的期望也正在发生根本性的变化：简单、便捷、透明、个性化以及社交化 。
选择了微服务架构也就意味着选择了一个开放、自由、大型的技术应用平台。微服务架构能 在任何操作系统和硬件配置上运行，现有的操作系统和硬件能被保留使用； 微服务架构可以
将通用的繁琐的服务端任务交给中间件完成，这样开发人员可以集中精力在如何创建商业逻 辑上，相应缩短开发时间。
目前保险企业各个业务系统存在较多应用竖井，每个竖井都需要通过专有的接口提供各自的服 务。依据业务发展趋势和建设规划，需要从面向系统转型面向服务，通过服务组件提供应用和 数据；需要进行架构解耦，消除应用竖井，让业务功能以标准化的业务服务形态暴露给最终用 户，使服务可共享并重复利用。通过建立微服务架构的IT平台将信息技术与业务的有效结合起 来，从而推动企业产品创新、服务创新及市场创新。
通过对现有各业务系统的整合，建立对内对外统一的、高效的平台，满足业务管理、 销售支持、决策分析等各方面需要；支持应用系统在不同用户界面或渠道的拓展， 如柜面、微信、APP、WEB、银保通、医保通。。。
微服务架构的目标
目标
期望的成果
• 以客户为中心，创建360度客户视图(客户画像)，更好 地理解客户，以个性化的方式与客户交流
微服务架构良好的开放性和兼容性，支持标准的协议和接口类型， 提供多种开放的应用开发 接口，能够和业界主流的产品实现互连互通，并具备有效的、统一的手段和机制进行业务管 理、设备管理、应用软件环境设置调整管理、开发管理以及运维人员的管理。
微服务技术架构
通过微服务解耦业务系统的各个业务功能，可以根据用户的需求灵活定制不同的用户界面与 具体功能。接口适配器池完成对不同业务系统的接口适配的功能，同时实现与合作伙伴的网 关接口连接和管理。
2017保险IT 微服务架构
Elvis Zhang 2016年10月
保监会发展改革部副主任罗胜在“2016中国互联网保险大会”上表示，大数据可能带来 保险产品、作业、组织、监管模式的改变。在大数据的支撑下，风险可以更精细划分， 保险作业更深更广融地入具体场景，即所谓场景保险。
保险产品可以更加碎片化；保险公司采取更多甚至全部在线的作业流程，即所谓保 险的O2O；保险公司内部完整作业链条的围墙被拆除、打碎后重新组装。
不断变化的市场环境需要IT平台可以针对产品、业务的迅速变化提供即时的支持，
例如产品规则的变化、新的业务流程的应用等。在开展新地区、新渠道或者新形态 的业务时，需要IT平台提供更加完整、丰富的数据支持。
随着保险产业网络的不断成熟，将出现大量在价值链的某些环节提供专业化服务的专家型企业， 保险价值链充分分离成大量由相应专业企业运作的业务功能，需要IT平台可以灵活、自由地和 很多外部伙伴的业务系统建立集成、合作关系。如何突破业务系统的制约，使企业在整个价值 链上进行优化，将成为企业降低运营成本、为客户提供更高效的服务，从而增强企业整体竞争 力的关键。