You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@apisix.apache.org by bz...@apache.org on 2022/03/03 08:07:28 UTC
[apisix-website] branch master updated: docs: add Zhongan Usercase blog (#933)
This is an automated email from the ASF dual-hosted git repository.
bzp2010 pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/apisix-website.git
The following commit(s) were added to refs/heads/master by this push:
new 10b17ec docs: add Zhongan Usercase blog (#933)
10b17ec is described below
commit 10b17ec950841b9aa7fac95f0c7ae8ea6dd09928
Author: Sylvia <39...@users.noreply.github.com>
AuthorDate: Thu Mar 3 16:07:02 2022 +0800
docs: add Zhongan Usercase blog (#933)
---
.../03/02/zhongan-usercase-with-apache-apisix.md | 132 +++++++++++++++++++++
.../03/02/zhongan-usercase-with-apache-apisix.md | 130 ++++++++++++++++++++
2 files changed, 262 insertions(+)
diff --git a/website/blog/2022/03/02/zhongan-usercase-with-apache-apisix.md b/website/blog/2022/03/02/zhongan-usercase-with-apache-apisix.md
new file mode 100644
index 0000000..8b5f645
--- /dev/null
+++ b/website/blog/2022/03/02/zhongan-usercase-with-apache-apisix.md
@@ -0,0 +1,132 @@
+---
+title: "How to Implement Traffic Governance in Internet Insurance with APISIX?"
+author: "Sylvia"
+authorURL: "https://github.com/SylviaBABY"
+authorImageURL: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- API Gateway
+- Internet Insurance
+- Apache APISIX
+- Zhongan
+description: In this article, we will introduce some business scenarios and practical cases of zhongan and bring you the gateway selection and implementation operation under the "Internet Insurance" scenario.
+tags: [User Case]
+---
+
+> The content of this article is sorted out from the relevant sharing brought by Xu Min, head of Zhongan Insurance and Technology Infrastructure in Apache APISIX Weekly Meeting.
+
+<!--truncate-->
+
+Zhongan Insurance is the first and the largest Internet insurance company in China, with sales using an all-Internet format for product sales, no offline agents, and online traffic mainly through self-operated, partner company websites and channels. By actively providing personalized, customized and intelligent insurance varieties, it makes up for the lack of product capabilities of traditional insurance companies.
+
+When looking at the technical level from the business perspective, there is a strong demand for traffic governance on the technical side in order to meet the complex business scenarios and the proprietary characteristics of the industry of Zhongan. In this article, we will introduce some business scenarios and practical cases of zhongan and bring you the gateway selection and implementation operation under the "Internet Insurance" scenario.
+
+## Business Scenario Features
+
+### Multiple Insurance Categories
+
+As we mentioned at the beginning, Zhongan, as the first Internet insurance company in China, offers a very wide range of insurance products, especially like property insurance. There are many kinds of property insurance, and there may be all types that you can think of, such as car insurance, broken screen insurance and health insurance, as well as the common daily shopping refund shipping insurance for Taobao, etc.
+
+Basically, as long as everyone encounters something in life, it may be designed as an insurance product, so the Internet insurance scene, the number of types of insurance products is its more characteristic background.
+
+### Multi Sales Channels
+
+Although it is said that all the operation process of Internet insurance is carried out online, it is a typical Internet+ scenario. It has both the high frequency and high concurrency of the Internet or some explosive phenomena, and also low frequency and low concurrency scenarios like others. However, it has both the flow characteristics of the Internet and also contains very many offline or traditional insurance business characteristics.
+
+To be more precise, many scenarios of Internet insurance rely on channels for entrance, and multiple channels enable the business to release more capabilities. Therefore, the management of channel traffic is also an important part of Internet insurance in realizing the business level.
+
+### Strong Supervision
+
+
+
+In addition to the business area, as an industry that deals directly with money, insurance is also part of finance, so it is a financial product that will be supervised by the CBRC just like banks and securities, and comply with the corresponding terms and conditions. At the same time, the CBRC basically puts forward different requirements for business and technical aspects every year, and these are to go along with and develop.
+
+For example, the red and green parts in the above diagram belong to the architectural approach for the separation of regulatory channels or front-end business from core business. Here there are also some regulatory requirements for the security level, including the governance of the two places and three centers and for the isolation of the middleware data business. The requirements for traffic governance and security are relatively strict.
+
+## Scenario Pain Points and Needs
+
+Considering the real use scenario, each company actually has different levels and needs for traffic management. For example, some companies may prefer the gateway to be more front-loaded and act as an edge gateway, while others may want the gateway to handle north-south traffic or co-manage east-west and north-south traffic.
+
+From some common perspectives (closer to the business scenario of Zhongan), the following pain points and solution directions have been sorted out, i.e. the shortcomings of the gateway level in the current business scenario and the action directions that we want to make up afterwards.
+
+
+
+And in the real scenario of gateway deployment, in addition to the above issues, it is also necessary to consider the overall business requirements and the adaptation of multiple types of gateways in the deployment process. The following figure shows the logical deployment in the traffic governance process, mainly involving traffic gateway, microservice gateway, unified operation gateway, BaaS gateway and domain gateway.
+
+
+
+After sorting out the current problems, the technical team of Zhongan started to focus the gateway selection on some more mature open source products and began a new round of exploration.
+
+## Target Apache APISIX
+
+Since Zhongan has defined "open source products" at the beginning of the selection process, it has given certain reference standards from the enterprise perspective in evaluating open source products, and has given Apache APISIX the most direct recognition from these perspectives.
+
+
+
+Of course, in addition to evaluating the open source products themselves, Zhongan also compared Kong and Traefik, which are still in use in the company's business, and also contacted the MSE products shared by AliCloud, among others.
+
+In the end, a comprehensive side-by-side comparison was conducted in the following projects, and it can be seen that Apache APISIX is well suited to Zhongan's business needs in both long-term and short-term planning at the enterprise level.
+
+
+
+## Apache APISIX Based Landing Case
+
+### Metering and Billing for BaaS Products
+
+Zhongan is now gradually BaaS its underlying products within the business. Because of the financial attributes, the implementation requirements for BaaS products will be higher, and the infrastructure products need to achieve the same unified standard measurement and billing as cloud products.
+
+
+
+Because all the products used in the company need to achieve financial statement-style regulatory requirements. Therefore, in this scenario, real-name authentication and related auditing functions are required, and the APISIX forensics module is needed here. This means that any call process within the company needs to be audited and recorded, including the number of calls, expenses incurred, etc. So in this process, Apache APISIX's powerful logging-related features also play a very good [...]
+
+At the same time, the audit process also requires peak audit calculations, which involves a lot of billing formulas that include not only the number of calls, but also peak information. So based on APISIX's functional support, we can also realize the presentation of relevant Metrics indicators, thus laying a solid foundation for metering and billing scenarios.
+
+
+
+The specific implementation framework can be found in the above diagram, where the configuration center is a pure layer 7 traffic protocol, so it can be fully integrated into the metering and billing system, including ES and APISIX itself, etc. The specific operation is mainly based on the current structure of APISIX to do some definitions, such as to call several requirements for the company's business, as well as using some plug-ins of APISIX for the implementation of related orchestra [...]
+
+### Multi-tenant and Multi-channel Traffic Segregation
+
+In the face of the multi-insurance multi-channel scenario of Zhongan, multi-tenant multi-channel traffic isolation has also become a requirement with industry characteristics.
+
+Based on Apache APISIX, Zhongan has also made some plans for the requirements and strong control in multi-channel scenario. Thanks to APISIX's powerful traffic orchestration and plugin orchestration functions, it provides a traffic precision control effect never experienced before in Internet insurance scenarios.
+
+For example, if some business parties are large and have large channels, they may create a separate cluster for the channels to use; but some channels are smaller, maybe 10% of them are large, but most of them are small. Based on such a scenario, one can try to fuse these small channels into one gateway entity or instance, and then share it.
+
+Of course here it will involve each application in the process of access, because different channels will have different upstream and downstream to dock, it will generate different domain names. The isolation based on this scenario (structured in the figure below) is called first-level isolation.
+
+
+
+But when the channel is docked in the need for follow-up related operations, although the process is exactly the same but the next business control capacity requirements are different from those mentioned above, so it is necessary to carry out secondary isolation of the channel again (as shown in the structure below). Through such a level of isolation plus two isolation mode, it can be a good solution to the gateway in the multi-tenant multi-channel traffic isolation.
+
+
+
+## Future Plan and Expectations
+
+### Strengthen Cross-departmental Synergy
+
+At present, Zhongan has not only one business, but also many subsidiaries, so we will definitely face many large-scale deployments of such multi-departmental business in the follow-up process.
+
+Therefore, when promoting the related technology stack, it must not be led by only one department, but more of a cross-departmental collaboration, so as to realize the deployment of Apache APISIX in Zhongan as soon as possible.
+
+### Update Nacos Service Registry Based on Apache APISIX
+
+At present, Zhongan is doing lossless service up/down based on Nacos, so in the following plan, APISIX will be interfaced with Nacos to achieve unified management. This will allow microservices to be routed to Apache APISIX for lossless or source data-based traffic distribution. Of course, we will also continue to use APISIX to improve BaaS-related capabilities.
+
+### Continue to Watch the Service Mesh Product
+
+However, because of the rapid development of business, the current service grid can not meet the current business implementation space. Therefore, we continue to look at external service grid products, such as APISIX Service Mesh, or try to use APISIX in combination with etcd.
+
+## Summary
+
+In the process of pursuing traffic governance and implementation of some ground plans, we are not only using Apache APISIX as an edge gateway to control point traffic, but also based on the overall architecture for traffic control. That is, for the whole DevOps lifecycle, such as whether the testing scenario can provide testing capability or multi-version development capability; whether the production side can provide traffic recording and playback capability; whether the big data depart [...]
+
+
+
+We hope that in the subsequent implementation practice, Zhongan can realize the complete implementation of overall traffic governance based on Apache APISIX, and help the traffic control and security governance in the Internet insurance field.
+
+:::note
+
+1. The specific terms involved in the architecture diagram in the text are all abstract understanding, not the real environment with words.
+2. API Gateway side-by-side comparison data comes from the Internet, which may deviate from the latest or real data, and does not represent the official website data.
+
+:::
diff --git a/website/i18n/zh/docusaurus-plugin-content-blog/2022/03/02/zhongan-usercase-with-apache-apisix.md b/website/i18n/zh/docusaurus-plugin-content-blog/2022/03/02/zhongan-usercase-with-apache-apisix.md
new file mode 100644
index 0000000..62e9cf4
--- /dev/null
+++ b/website/i18n/zh/docusaurus-plugin-content-blog/2022/03/02/zhongan-usercase-with-apache-apisix.md
@@ -0,0 +1,130 @@
+---
+title: "如何借助 Apache APISIX 实现互联网保险领域的流量治理？"
+author: "Sylvia"
+authorURL: "https://github.com/SylviaBABY"
+authorImageURL: "https://avatars.githubusercontent.com/u/39793568?v=4"
+keywords:
+- API 网关
+- 互联网保险
+- 众安保险
+- Apache APISIX
+description: 本文将通过介绍众安保险的一些业务场景与实践案例，为大家带来关于互联网保险场景下的网关选型与落地操作。
+tags: [User Case]
+---
+
+> 本文内容整理自 Apache APISIX Weekly Meeting 中众安保险和科技基础架构负责人徐敏带来的相关分享。
+
+<!--truncate-->
+
+众安保险是中国首家和规模最大的互联网保险公司，销售采用全互联网形式进行产品销售，不设线下代理，线上则主要通过自营、伙伴公司网站、渠道等方式获取流量。通过积极提供个性化、定制化和智能化的保险品种，弥补了传统保险公司产品能力的不足。
+
+从业务角度来看技术层面时，为了满足众安保险的复杂业务场景和行业的专有特性，就会对技术侧的流量治理产生了强烈的需求。本文将通过介绍众安保险的一些业务场景与实践案例，为大家带来关于「互联网保险」场景下的网关选型与落地操作。
+
+## 业务场景特点
+
+### 多险种
+
+开头我们提到过，众安保险作为国内第一家互联网保险企业，提供非常多的保险品种，特别是像财产险。财产险的种类可谓是繁多，大家想到想不到的类型可能都会有，比如车险、碎屏险和健康险，还有日常常见的淘宝购物退运费险等等。
+
+基本只要是大家生活中遇到的东西，都有可能会被设计成一种保险产品，所以互联网保险场景下，险种产品之多是其比较有特色的背景。
+
+### 多渠道
+
+虽然说互联网保险的所有操作流程都在线上进行，是典型的互联网+场景。它既有互联网的高频高并发或者说是一些爆款现象，也有像其它的低频低并发场景。但它既有互联网的流量特性，同时也还包含非常多的线下或者传统保险的业务特性。
+
+更准确地说，互联网保险的很多场景入口依赖渠道进行，多渠道使得业务能够进行更多能力的释放。所以对于渠道流量的管理，也是互联网保险在实现业务层面的重要一环。
+
+### 强监管
+
+
+
+除了业务领域，作为与钱直接打交道的行业，保险也属于金融的一部分，所以是和银行、证券一样会受到银保监会监督的金融产品，并遵守对应的条款。同时银保监会基本上每年都会针对业务和技术层面提出不同的要求，这些都是要去配合和发展的。
+
+如上图中红色和绿色部分，就属于针对监管渠道或前置业务与核心业务分离的架构方式。在这里对于安全层面也存在一些规范要求，包括两地三中心的治理和针对中间件数据业务的隔离，对流量治理和安全性的要求相对是比较严格的。
+
+## 场景痛点与需求
+
+考虑到真实使用场景，每家公司对于流量治理的层次和需求其实也各不相同。比如有些公司可能相对来讲更希望网关更前置，仅作为边缘网关角色，有些可能希望网关能够处理南北流量或者是东西、南北流量共同治理。
+
+这里从一些共性角度（更贴近众安保险的业务场景）大概整理出了以下几个痛点跟解决方向，即当下业务场景内网关层面的不足以及之后想要弥补的动作方向。
+
+
+
+而在网关部署的真实场景下，除了上述问题之外，还需要考虑整体业务需求与部署环节中多类型网关的适配。下图展示的是在流量治理过程中的逻辑部署，主要涉及流量网关、微服务网关、统一运营网关、BaaS 网关和域网关。
+
+
+
+在梳理清晰当下问题后，众安保险的技术团队开始将网关选型聚焦在一些比较成熟的开源产品之上，开始了新一轮的探索。
+
+## 锁定 Apache APISIX
+
+由于众安保险在选型之初就框定了「开源产品」，所以在评估开源产品的层面，也从企业角度给出了一定的参考标准，并从这些角度给予了 Apache APISIX 最直接的肯定。
+
+
+
+当然，除了对开源产品本身角度的评估外，众安保险也对比了目前公司业务中仍在使用的 Kong 和 Traefik，同时也接触了阿里云分享的 MSE 产品等。
+
+最终在以下项目中进行了全面的横向对比，可以看到不管是在企业级的长期规划还是短期规划中，Apache APISIX 都能很好地满足众安的业务需求。
+
+
+
+## 基于 Apache APISIX 的落地案例
+
+### BaaS 产品的计量计费
+
+众安保险目前正在业务内部逐步将底层产品 BaaS 化。由于是金融属性，所以对于 BaaS 产品的落地要求会更高，需要将基础架构产品与云产品一样实现统一标准的计量计费。
+
+
+
+因为公司内部用到的所有产品，都需要实现财务报表式的监管要求。因此在这种场景下，就需要实名认证和相关审计功能，这里就需要用到 APISIX 的鉴权模块了。也就是说公司内部的任何调用过程都需要被审计记录，包括调用次数、发生的费用等。所以在这个过程中，Apache APISIX 强大的日志相关功能也是起到了很好的支持。
+
+同时在审计过程中也需要进行峰值审计的计算，这里就会涉及到很多计费公式，这里的计费公式里不仅有调用量，还有峰值等信息。所以基于 APISIX 的功能支持也可以实现相关 Metrics 指标的呈现，从而为计量计费场景奠定坚实基础。
+
+
+
+具体的实现框架可以参考上图，其中配置中心是一个纯七层流量的协议，所以可以完全纳入到计量计费体系中，包括 ES 以及 APISIX 本身等。具体操作主要是基于 APISIX 目前的结构做了一些定义，比如去调用几个针对公司业务的需求，以及使用 APISIX 的一些插件进行相关编排能力的实现。
+
+### 多租户多渠道流量隔离
+
+面对众安保险的多险种多渠道使用场景，多租户多渠道的流量隔离也成为具备行业特征的需求。
+
+而基于 Apache APISIX 的落地实践中，众安也针对多渠道场景下的要求与强管控进行了一些规划。得益于 APISIX 强大的流量编排和插件编排功能，为互联网保险场景下提供了之前从未体验过的流量精密控制效果。
+
+比如有的业务方规模比较大，渠道也很大，就可能会把渠道单独建立一个集群来用；但有些渠道规模较小，可能 10% 的规模是大的，但大部分都很小。基于这样的场景，就可以尝试将这些小渠道融合到一个网关实体或实例里，然后再进行共享。
+
+当然这里就会涉及到每个应用在接入的过程中，因为不同渠道会有不同的上下游去对接，就会产生不一样的域名。基于这种场景的隔离（如下图结构）称之为一级隔离。
+
+
+
+但当渠道对接进来后就需要进行后续相关操作，虽然流程是一模一样但接下来业务的管控能力要求是与上边提到的不同，所以就需要再对渠道进行二级隔离（如下图结构所示）。通过这样的一级隔离加二级隔离模式，就可以很好地解决了网关在多租户多渠道中的流量隔离。
+
+
+
+## 后续规划与期望
+
+### 加强跨部门之间的协同
+
+目前众安保险不仅仅只有这一项业务，同时旗下还有非常多的子公司，在后续的推进过程中一定会面临很多这样多部门业务大规模的部署。所以在推进相关技术栈的时候，一定不是只由一个部门去主导，更多的是跨部门之间的共同协作，从而尽早实现 Apache APISIX 在众安的落地部署。
+
+### 基于 APISIX 更新 Nacos 注册中心服务
+
+目前众安保险内部正在基于 Nacos 进行服务的无损上下线，所以在后续规划中会将 APISIX 与 Nacos 对接实现统一管理。这样就可以将微服务通过路由方式对接到 Apache APISIX，达到无损或基于源数据的流量分发效果。当然也会继续借助 APISIX 来完善 BaaS 的相关能力。
+
+### 持续观望服务网格产品
+
+众安保险内部目前是在进行自己平台的服务网格搭建，但因为业务发展迅速导致目前的服务网格运行状态满足不了当下业务落地空间。所以也在持续关注外部的服务网格产品，比如 APISIX Service Mesh，或者是尝试利用 APISIX 与 etcd 的结合方案。
+
+## 总结
+
+纵观众安保险在追求流量治理和一些落地规划执行的过程中，不仅仅是把 Apache APISIX 作为一个边缘网关角色去控制点状流量，更多的则是基于整体架构进行流量的控制。即面向整个 DevOps 的全生命周期，进行诸如测试场景是否能提供测试能力或者多版本开发能力；生产侧提供流量录制、回放能力；大数据部门是否可以生产相关的沙箱环境，来评估更好的模型并进行域环境的隔离等能力。
+
+
+
+希望在后续的落地实践中，众安保险可以基于 Apache APISIX 实现整体流量治理的完整落地，助力互联网保险领域的流量管控与安全治理。
+
+:::note
+
+1. 文中架构图涉及到的具体名词全部为抽象理解，非真实环境用词。
+2. API Gateway 横向对比部分数据来源于互联网，可能与最新或真实数据存在偏差，不代表官网数据。
+
+:::