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

Editor: the best work that talks about microservices as approachable.

First, the landing of micro-services is a complex issue, which involves many aspects of IT architecture, application architecture and organizational architecture.

The application layer needs to deal with these 12 problems, the last one can not be less, the implementation of micro-services, are you ready? Do you really think that by saving springcloud, you can do this well?

4.2. The operation and maintenance mode of stage 3

To the micro-service stage, after the implementation of containerization, you will find that, however, the original operation and maintenance should have done the development, the development of the boss is willing? Does the developer complain against the boss of operation and maintenance?

This is not a technical problem, in fact, DevOps,DevOps does not distinguish between development and operation and maintenance, but the company can get through from the organization to the process to see how to cooperate and how to demarcate the boundaries, which is more beneficial to the stability of the system.

In fact, development and operation and maintenance have become a process of integration, and development will help operators do some things, such as the advance of environment delivery and the writing of Dockerfile.

Operation and maintenance can also help R & D to do some things, such as registration discovery, governance, configuration between micro-services, etc., it is impossible for each business of the company to have a separate framework, which can be sunk to the operation and maintenance group to become a unified infrastructure and provide unified management.

After the implementation of containers, microservices, and DevOps, the entire division of labor interface looks like the following.

This is the model in NetEase. Hangzhou Research Institute, as a public technical service department, has an operation and maintenance department to manage the computer room, and the above is the cloud platform group, which has developed a cloud platform that tenants can operate by themselves based on OpenStack. PaaS components are also part of the cloud platform, which are available to provide SLA protection. The container platform is also part of the cloud platform and provides a continuous integration and continuous deployment tool chain based on containers.

The management and governance of micro-services is also part of the cloud platform, which business units can use to develop micro-services.

The middleware group or architecture combination cloud platform group of business units communicate closely, mainly on how to use cloud platform components in the correct posture.

The business department is divided into front-end group, business development group and Zhongtai development group.

How to implement micro-service, containerization, DevOps

The implementation of micro-services, containerization, DevOps has a lot of technology selection.

Kubernetes is a well-deserved choice for the containerization part. But Kubernetes doesn't just focus on containers, it's designed for micro-services. It is involved in all aspects of the implementation of microservices.

Analyze in detail why kubernetes is naturally suitable for micro-services, but Kubernetes is relatively perfect for container runtime life cycle management, but not strong enough for service governance.

Therefore, for the governance of micro-services, we choose to use Dubbo or SpringCloud. There are many stock applications that use Dubbo. Compared with Dubbo, SpringCloud is relatively new and rich in components. However, the components of SpringCloud are not ready to be used out of the box and require a relatively high learning curve.

Therefore, based on Kubernetes and SpringCloud, there is the following integrated management platform for micro services, containers, and DevOps. Including Kubernetes-based container platform, continuous integration platform, test platform, API gateway, micro-service framework, APM application performance management.

The main purpose is to solve the pain points in the improvement from stage 1 to stage 2, or from stage 2 to stage 3.

Let's list a few scenarios.

Scenario 1: how to ensure that the regression testing feature set remains unchanged when the architecture SOA is split

As mentioned earlier, after the service is split, the biggest fear is to introduce a lot of bug. Through reason, there is certainly no guarantee that the feature set will remain the same after the split, so there needs to be a regression test set. As long as the test set passes, there will be no big problem with the function.

Regression testing is best based on interfaces, because UI-based interfaces are very dangerous, and some interfaces are available, but you can't click on UI. If this interface has Bug, it is temporarily hidden. When there is a new requirement, when the developer finds that there is an interface that can be called, it dies as soon as it is called.

With Restful API-based interface tests, you can form scenario tests that combine multiple API calls into one scenario, such as placing orders, deducting coupons, and reducing inventory, which is a combined scenario.

In addition, a test set can be formed, such as a smoke test set, which can be executed when the developer delivers the function to the test. Another example is the daily test collection, which runs every night to see if any new bug has been introduced into the code submitted that day. Another example is to return to the test set and run it again before going online to make sure that most of the functions are correct.

Scenario 2: how to uniformly manage and provide mid-platform services when the architecture is SOA?

When a business wants to provide a Zhongtai service, the Zhongtai service first wants to be registered to a place where, when the business group develops business logic, it can find documents on how to invoke the interface of the business group. when the business group's business is registered, it can be called.

In addition to the general registration discovery function of the micro-service framework, it also provides the function of the knowledge base, so that the interface and document are maintained uniformly, and the document is consistent with the runtime, so that the caller can call when looking at the document.

In addition, the authentication function during registration, discovery and invocation is provided. Not everyone who sees the server can be called, and the administrator of the server is required to authorize it.

In order to prevent the service from being called maliciously, the account audit function is provided and the operation is recorded.

Scenario 3: how to ensure the security of key service invocation when service is SOA

Some services are very critical, such as payment services, which are related to funds, which can not be invoked by anyone who wants to call them. Once they are invoked illegally, the consequences will be serious.

There is a routing feature in service governance. In addition to configuring flexible routing features, you can also configure blacklist and whitelist, which can be based on IP address or service name, and which applications can be called to cooperate with the VPC feature of the cloud platform to restrict callers.

Scenario 4: after the architecture is SOA, API services are provided to build an open platform.

After the SOA architecture, in addition to providing internal Taiwan services, many capabilities can also be opened to external partners to form an open platform. For example, if you are a logistics company, in addition to placing an order on your page to send express delivery, other e-commerce can also call your API to send express delivery, which requires an API gateway to manage API. As long as your e-commerce is logged in to this API gateway, you can see API and how to call it. This is the role of document management on the API gateway.

In addition, the API gateway provides unified authentication and authentication of the interface, and also provides the timing switch function of the API interface to flexibly control the life cycle of the API.

Scenario 5: grayscale release and Aamp B testing in the Internet scenario

Next, we switch to the Internet business scenario, and we often do the Amax B test, which requires the traffic distribution function of the API gateway.

For example, when we do Internet business, it is not clear whether customers like it or not, so we can first open it to customers in Shandong. When there is a field from Shandong in the HTTP header, access system B, and other customers still access system A. at this time, we can see whether customers in Shandong like it or not. If they all like it, push it to the whole country. If they don't like it, take it down.

Scenario 6: pre-launch testing in the Internet scenario

This is also an advance test that is often encountered in Internet scenarios. Although we have tested many rounds in the test environment, because the online scenario is more complex, sometimes we need to use online real data for testing. At this time, you can deploy a set of pre-sent environment next to the online formal environment, and use the API gateway to mirror part of the real request traffic to the pre-sent environment. If the pre-issued environment can correctly handle the real traffic, it will be much more relieved to go online.

Scenario 7: performance stress testing in Internet scenarios

In order to know the real bottleneck point of the whole system, the real online performance test should be done under the Internet scene. However, the performance test data cannot be entered into the real database, so you need to enter the shadow database, and the performance test traffic also needs to be marked in the HTTP header to let the passing business system know that this is the test data and does not enter the real database.

This special tag needs to be added in the API gateway, but due to the different requirements of different pressure testing systems, it is necessary for the API gateway to have a custom routing plug-in function. You can add your own fields to the HTTP header at will to cooperate with the pressure testing system.

Scenario 8: circuit breaker, current restriction and degradation in micro-service scenario

In micro-service scenarios, circuit breakers, current limits and downgrades are required when there is a big boost. This can be done in the API gateway, will exceed the measured value of the flow, through the current limit, block outside the system, so as to ensure that the flow as much as possible, the order can be placed successfully.

Between services, you can also circuit breaker, limit current, and downgrade through the micro-service framework. Dubbo's control of services is at the interface level, and SpringCloud's management of services is at the instance level. The two customers with different granularity have different choices. Both use Dubbo granularity too fine, and both use SpringCloud granularity too coarse, so they need to be configured flexibly.

Scenario 9: fine traffic management in micro-service scenarios.

In Internet scenarios, fine management of traffic is often needed, and traffic can be diverted according to the parameters in HTTP Header. For example, VIP users access one service and non-VIP users access another service. In this way, more high-quality products can be recommended to high-income users and the connection rate can be increased.

This article is from: Liu Chao's popular cloud computing.

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.