Shulou(Shulou.com)06/02 Report--

Reprint this article need to indicate the source: Wechat official account EAWorld, violators will be prosecuted.

Introduction:

According to the development trend of the insurance industry, insurance transactions have shown the characteristics of high frequency, fragmentation, scene and so on, which puts forward higher requirements for the processing capacity, capacity, business continuity, demand corresponding speed and operation and maintenance response speed of the system. The innovation and reshaping of business model leads to frequent system updates, a sharp increase in application complexity, overburdened traditional architecture, agile development and rapid delivery.

The implementation goal is to build a micro-service management platform and supporting tools to meet the business needs of XXX insurance companies, including: micro-service development framework, micro-service registration platform, micro-service management platform, etc., which can support micro-service development and operation life cycle management, and then better support business and technology development and innovation.

Table of contents:

I. Project background and objectives

II. Architecture design of micro-service platform

3. Micro-service invocation relationship

Fourth, the design of micro-service access authentication.

I. Project background and objectives

According to the development trend of the insurance industry, insurance transactions have shown the characteristics of high frequency, fragmentation, scene and so on, which puts forward higher requirements for the processing capacity, capacity, business continuity, demand corresponding speed and operation and maintenance response speed of the system. The innovation and reshaping of business model leads to frequent system updates, a sharp increase in application complexity, overburdened traditional architecture, agile development and rapid delivery.

The main problems faced by customers are:

Applications based on single architecture or SOA architecture can not meet the needs of business model innovation.

Lack of unified technical standards and architecture for micro-service applications

The pilot project of micro-service architecture reflects the urgent need to improve the control and governance of services.

The goal of customer micro-service platform customization is to build a micro-service management platform and supporting tools to meet the needs of insurance business in the new situation, which can support the development and operation life cycle management of micro-services, which mainly include:

Micro-service development framework: a service framework base for developing micro-services

Micro-service registration platform: complete lifecycle management of micro-service design, development, change, version, subscription, removal, etc.

Micro-service management platform: micro-service runtime management, including service registration, service discovery, configuration center, gateway, load balancing, authentication, fuse degradation, monitoring and other functions.

II. Architecture design of micro-service platform

The enterprise distributed application platform based on micro-service architecture is divided into integrated development tools, service running environment, application management and monitoring, external channel access and other dimensions. Its functional architecture is shown in the figure, including SDK& specification, registration center, configuration center, monitoring center, certification center, API gateway, service running environment, management platform, registration platform and so on.

Logical architecture of micro-service platform

Conceptual model of micro-service platform

According to the actual situation of customers, the conceptual model of micro-service platform is defined as follows:

Registry: supports the registration of all micro services under all domains in an environment

Configuration Center: supports the configuration of all micro-services under all domains in an environment

APM: supports APM monitoring of all micro services under all domains in an environment

Circuit breaker monitoring center: supports circuit breaker monitoring of all micro-services under all domains in an environment, and supports viewing by each version

Log center: supports log collection and viewing of all micro-services under all domains in an environment

Domain: corresponds to a complete business domain, such as car insurance domain

Gateway: gateways are divided into external gateways and internal gateways. The external gateway is deployed in the DMZ area to expose the API external network, and the internal gateway is used for cross-system API calls.

System: corresponding to the actual business system, each domain has multiple business systems

Application: corresponding to the business module in the business system, each business system has multiple applications

Microservices: there are multiple microservices per application

Microservice version: each microservice can have multiple versions, among which there can be multiple live versions.

API: the API provided by each microservice version

Example: the running process of each microservice version

3. Micro-service invocation relationship

The invocation relationship between microservices can be divided into two scenarios: intra-system and cross-system:

1. Calls between microservices within the system

In the directly connected mode, when microservice multiple instances are deployed, the caller uses a client-side load balancer (such as Netflix Ribbion).

2. Calls between cross-system micro-services

Cross-system micro-service calls are transferred through the API gateway, and the service provider needs to configure routing on the API gateway, and then publish the API in the API Store

The service consumer subscribes to the required API through API Store and obtains the subscription code, and then calls the subscribed API with the subscription code.

API Store supports the subscription audit process, and the service provider can audit the subscription requests of consumers.

Note: API Store is a customized module for managing service publication and subscription, which is not described here.

In the actual business scenario, multiple versions co-exist in the run-time of micro-service providers, so API gateway and micro-service SDK support micro-service multi-version routing strategy:

The client request header specifies the target service version to be invoked

Support grayscale version policy: allow or disallow access to grayscale versions (that is, blacklist and whitelist) for a specific group of callers, that is, grayscale versions import part of client traffic

Support for online hot conversion of grayscale version to official version

Fourth, the design of micro-service access authentication.

The process of service invocation includes the process of service publishing and service consumption.

In different service invocation scenarios, API gateways and service providers need to authenticate the identity of consumers and authenticate service invocations.

The API gateway is responsible for verifying the validity of the client subscription code (calling API authentication service for authentication) and supporting blacklist and whitelist configuration, while the micro service provider (SDK) is responsible for verifying the legitimacy of the client (internal service or API gateway) identity.

Design of micro-service access authentication

1) when the service consumer invokes the API of the service provider through the API gateway, it needs to carry the subscription code in the request header.

2) according to the subscription code in the request header, the API gateway calls the authentication service to verify the validity of the request, and rejects the illegal request if authentication fails.

3) after the API gateway authentication is successful, delete the subscription code in the request header to avoid revealing the security information of the service consumer to the service provider, add the API gateway identity to the request header, and then forward it to a backend API service provider instance according to the current routing rules

4) the service provider receives a call request from the API gateway or other micro-services within the system, obtains the client ID in the request header, obtains the client instance list from the service registry, compares whether the source of the request is in the instance list, and verifies whether the request comes from a legitimate consumer.

The following is an example of Java client call. The parameters required for the call, such as subscription code, can be configured on application.yml (application.properties) or configuration center. The request header for authentication has been encapsulated in the Microservice SDK development kit.

Sample Java client invocation

The above is an implementation case of an insurance company's micro-service platform to share all the contents of service invocation and authentication under the micro-service architecture.

Selected questions:

Q1: "the process of service invocation includes the process of service publishing and service consumption". Here we talk about "authentication of service consumption". Is there any need for authentication in "service publishing"?

A: when API publishes, you can set whether approval is required. When service consumers subscribe to API, API Store will determine whether to submit it to the service provider for subscription approval according to the setting of whether approval is required. Only after approval is approved can the subscription be considered successful before calling. The service publication itself is now controlled by the user rights of API Store and published by the provider's administrator.

Q2: system A does not allow access to system B's service 1, but can access system B's service 2, while service 2 accesses service 1 directly through the system, so: when system An is authorized or accesses service 2, will the API Store or API gateway indicate the risk?

Answer: it will not be prompted that system B's service 2 will not be restricted from calling its own internal service 1. Gateway authentication is only concerned with whether system A calls system B's services legally.

About the author: Li Zhongwen, Puyuan development engineer, one of Puyuan DevOps core members. Participated in Societe Generale, Shanghai Volkswagen, Beijing Customs, Bank of China Card Center, China UnionPay and other projects

About EAWorld: micro services, DevOps, data governance, mobile architecture original technology sharing.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.