 Hello, everyone. I'm Chou Moon from Huawei. Our topic today is companies and sales match up with automobile companies, IT infrastructure. I will introduce sales match practice in production environment. Since launch in 2018, Huawei application sales match has served a large number of customers. The practice is part one of them. A leading automobile manufacturer in China. I will introduce how cloud native help upgrade the IT infrastructure. About me, an architect of Huawei application sales match currently developed cloud native projects such as sales match, Kubernetes, and Microsoft. And also help promote sales match and cloud native in China. I'm also of cloud native sales match history, how people learn sales match and history. My talks include four and three parts. The first part is consumer business background and the current solution. The second part is about the challenge of current solution and most importantly, target cloud native solution to solve these challenges. And finally, I will introduce auto migrate current solution for target cloud native solution. Our customer is a leading automobile manufacturer with the growth of automobile demand in China. The companies still needs to develop dramatically, especially with their new energy vehicles and put great pressure on their IT infrastructure, such as increased complexity and application becomes complicated and need to integrate with other platform. Also increased capacity and number of vehicles increased. Also the most secure requirements include excess control and the excess authentication. Also having jobs work are high and high actually costs are big problems. This is a current architecture. The customer actually engineer to us. They seem known for the popular Microsoft framework several years ago. Instead, they're all Microsoft platform, based on DNS, ERB and NGX and provide a service discovery for advancement in dependent platform rather than in education. The total architecture greatly depends on the central ERB which provides for internal service communication. And DNS is responsible for internal service resolution. ERS and JAX provided care estimation for the ERS traffic. And Zoom played the role of outstanding application delivery in JAX on additional process traffic for local service instance. To better understand the difference of current solution and the target cognitive solution, we will compare the abstraction view to architectures. Abstraction of the current architecture will look like this. The top is application layer. Applications are developed with multi-language. And the third layer is responsible for deploying environment. Currently, applications are deployed on working machine and the DNS. The central part is the second layer provides service management by integrating the ERB, DNS and NGX. Because of the second layer, Microsoft's platform, self-application are mainly developed in screen-foot instead of screen-cloud. And this is the abstraction of target solution compared to the previous one. And the main difference is the second layer and the third layer, replacing the ERB, DNS and NGX integrated platform with unified SysMatch infrastructure and upgrade deployment from VAM and VMS to commits. We can see the tools of architecture have changed a lot. So our customer engineer called the current solution self-developed match-like infrastructure before the period of SysMatch. Next, we will introduce the challenge of current solution through several aspects and focus on how the target cognitive solution solves this challenges perspective. First, let's see the search discovery and role balance. With current solution, DNS and ERB, they are important role in search discovery and role balance. There is a real instance to ERB registers SysMain and ERB IP to DNS. Consumer called DNS and sent a request to resolve ERB IP and ERB management traffic to select real instance. Per known NGX process request to local service and with target solution, Kubernetes and Istio known NGX service register. Istio will automatically retrieve registered data from Kubernetes and set process in a set traffic and perform service discovery. Then send a request to one select real instance and the server set process in the set traffic and perform server set traffic management. Compare two solutions by following views. First, as for service registry, a former NGX service name and ERB register to DNS and the latter known in the registry. And then for service discovery, the former is by ERB and DNS and the latter is dynamic data plan and control plan. The former role balance greatly depends on ERB and the latter is by client set process. When deployed a new service with current solution on the registry, there is had to manually register new service name to DNS by the target solution. Istio can get the service and its search instance automatically from Kubernetes. With current solution, consumer need to send a request to internal ERB and ERB and NGX act as a static proxy. And with target solution, consumer sending request to a target service request is accepted by much data which act as a transparent proxy for form service discovery and maintenance. Next is canary release. Canary is one important part in our customer's data work with current solution. The ERB is responsible for routine traffic to various instance and the traffic to a different version depends on the number of instances. There are three instances of version one and two instances of version two. So that 60% of traffic will be sent to version one and 40% will be sent to version two. With target solution by Istio, traffic rate for different version can be specified. With our version controls proportion of traffic each version and this date. For them as above rule, we resort 30% traffic to an instance of version two and the other 70% traffic will be available to version one. No matter how many instances this version has. It says providing routine policy, such match can control all of the traffic much that condition is looking to a certain version. The condition is related to protocol as for HTTP. The condition can be HTTP header path, source IP and so on. This manifest makes with DTV group header is sent to version two and the other still is sent to the default version one. With target solution, source match can do canary release for a group of cells just send the route for the first cells and the other set in the group for the following route. Mixed traffic from version one is sent to version one and from version two, it's sent to version two. This table summarized difference of two canary as for weighted policy with the current solution which is controlled by instance number and with target solution with weight can be specified flexibly and former than the last part of traffic match policy and later can control traffic to a certain version according to match condition. And current solution now support out for traffic always support out for traffic and target solution can support both L7 and L4 include TPD, TIS, HTTP, and with current solution some L7 policy is developed in application code but with target solution or a back platform no need any changing of application code. As mentioned in application back one that I need to resume security requirement for the development of customer business by with current solution all in KLS termination is provided or in grass traffic that is injects provide KLS termination all application have to develop HTTBI service and maintain key and the certificate by themselves and access control is embedded in the application for some confidential in place and with the target solution system I have to provide transparent security variety as termination by gateway or greater only to upload key and certificate in the form of commit secret I need to also offer as mutual tiers for authentication just a email email void result and service cost changes includes provide service to service secure service to service communication and provide each service with an authentically representing is equal and also can all make key and a certificate condition, position and distribution provide authorities access control for target service or target service in place these people also shows the difference of security both provide KLS termination and JLT authentication other former does not provide any service to service security and other provides mutual tiers authentication or transparency transparent tiers encryption or key management system automated key and certificate generation distribution and rotation and provide flexible access control custom condition such as either source or target access and target solution need our customer security perfected in its practice when a system becoming complicated need observability or top short and optimize the applications by the way it's kind of solution or in parallel to NJACs generate access as well and NJACs export export metric choosing agent in this node can generate system for Java applications or with target solution you still can generate metric present access level for all service by cell cards service developers do not need any extra work for this first proxy will generate service on key metrics covers latency, errors and situations and also generate spans on behalf of applications Chelsea can also generate access log for service traffic compare the two solutions in this table the main difference is that so much can help collect the observability data for and language with more accessibility transparency and flexibility Chelsea can generate all kinds of metrics and the metadata all dimensions can be configured perhaps they can generate spans for applications applications only need to propagate several request papers and cause they generate access log so that a lot can also be configured and also based on the access metric topology can be built give a global view of the application and services OK this is the target calling this architecture this we will look like this our unified infrastructure companies used to work together not only provide application defined environment but also provide self-managing platform covers panel release search discovery load balancing and measurement circuit breaker forward injection traffic mirror which are in the direction authentication and authority also provide magic crystal and stone we can see the data plan works as a transparency approach perform traffic management security and also build it on behalf of applications and in broad speedway give more flexibility the injects can manage traffic together with the circuits and control plan is responsible for boring and managing the configuration and distribute the policies to processes and circuits and there is another way of solution and the solution can easily configure or integrate with consumers existing canary kiosk and platform and magic login triscent system as separating all common functions from application code and also for infrastructure solution can help developers focus on the business summary about aspects of this table the key difference is architecture and mechanism the former is an intuitive platform provide a basic self discovery and advance and the latter is an infrastructure designed to handle application and communication as for components the former platform consists of different components there will be signals and injects and the latter is a unified infrastructure including control plan and data plan both these processes are the former really aesthetic process and the latter is the transparent process can be the tech and the managed service traffic this may be the biggest difference and the most important characteristic of CSMASH as for box work the former greatly depends on manual operation and the latter most likely works automatically as for CSMASH the former only provides self discovery and advance which is coded in application better provide powerful CSMASH and covers connection observation and security and this difference results in both cost and result reduction of customer to give the IT investment next the path found is called to migrate your migrate user's current solution to target community solution safely and gracefully the main idea is to develop a new environment with target solution and gradually speed up traffic on the cloud to cover this question to ensure reliability of one last test it is required to manage service to offer to when your commitment distance are available first to to determine the other distance and the commitment distance it is required the other distance and commitment distance found to last service shall the CSMASH discovery and advance and our solution is last service refer to commitment and commitment distance that is that the same way policy lecture and the rule of traffic to both community and environment as in this case my consumer service called target service vehicle traffic can be ruled to commitment distance also commitment to commitment distance that and the most important it is required to retry commitment distance and commitment distance not work and our solution is that we try the most located to specify which type of grant and commitment distance and the other vehicle the process will look like this request to commitment distance feels for some variable environment or long term reason automatically we try to remove the grant distance which had a success and the consumer request success finally it is required and the rule of commitment traffic to commitment distance with higher priority fuel or through grant reasons only when commitment distance are not healthy and our solution is by use of local locality but when commitment split a small part of traffic to grant distance and commitment distance are not healthy so switch all traffic to grant when the commitments are totally unhealthy and showing this table in a half of the traffic instance are unhealthy it still can get seventy percent of traffic it is required to make sure both primary and secondary instance and the secondary grant instance meets the traffic capacity requirement and that's all of our practice simply for the time