Recommended
Recommended
More Related Content
Similar to [2019]Version-based Microservice Analysis Monitoring and Visualization
Similar to [2019]Version-based Microservice Analysis Monitoring and Visualization (20)
Recently uploaded
Recently uploaded (20)
[2019]Version-based Microservice Analysis Monitoring and Visualization
- 1. Version-based Microservice Analysis, Monitoring, and Visualization I-Hsiu Liu , Jiun-Ting Lin , Shang-Pin Ma , Chun-Yu Chen , Nien-Lin Hsueh National Taiwan Ocean University 2019/12/03
- 3. 3 Microservice Architecture https://imgbin.com/png/M1SimDy5/dependency-graph-boost-library-graph-tool-png Highly dependent microservice system may undergo expansion such as the release of new versions. It becomes the problem of "Dependency Hell".
- 4. Challenge1: To clarify and control dependencies between services and versions ▰ Complicated dependency relationships between microservices ▰ Tracking of microservice versions ▻ Using Semantic versioning (SemVer) to avoid problem. 4 The current systems lack a visual overview that includes services, endpoints, and versions.
- 5. ▰ Traditional monitoring methods are poorly suited to systems comprising microservices. Challenge2: To monitor dynamic distributed systems 5 Developers would like to know the current status of the service.
- 6. Challenge3: To detect anomalous microservices Using any single measurement standard for the detection of all types of service anomaly would be unworkable. 6https://www.grandsys.com.tw/news/rd/879-microservice We need the proper tools for anomaly detection.
- 7. VMAMV (Version-based Microservice Analysis, Monitoring and Visualization) 1. Scanning & marking relationships and versions 2. Visualization 3. Service status updating 4. SPC-based monitoring 5. Anomaly notification System Features 7 Challenge 1 Challenge 2 & Challenge 3
- 8. ▰ Version-based Microservice Analysis, Monitoring and Visualization Service (VMAMVS) ▰ Microservice Code Analyzer (MCA) ▰ Service Registry Register (SRR) 8 System Architecture
- 9. Semantic Versioning 9 The version number format is as follows: X.Y.Z (Major.Minor.Patch) ▰ Major version → Making imcompatible modifications. ▰ Minor version → Adding functionality or making alterations. ▰ Patch version → Making a backward-compatible bug fix.
- 10. New and Old Patch Version Service 10 ▰ In Semantic Versioning, the increment of the patch version represents a backward- compatible bug fix. ▰ Any outdated patch version should be removed as soon as possible to prevent the problem persisting in the system.
- 11. Null Dependency Determination 11 ▰ Null Dependency means that a node which does not exist in the system is still dependent and the node is called a null node.
- 12. Statistical Process Control (SPC) 12 SPC is a quality control method and it can detect anomalies shortly after they occur. There are three lines in the control chart: 𝐶𝐿 (𝐶𝑒𝑛𝑡𝑒𝑟 𝐿𝑖𝑛𝑒) = 𝑥 𝑈𝐶𝐿 (𝑈𝑝𝑝𝑒𝑟 𝐶𝑜𝑛𝑡𝑟𝑜𝑙 𝐿𝑖𝑚𝑖𝑡) = 𝑥 + 3𝜎𝑥 𝐿𝐶𝐿 (𝐿𝑜𝑤𝑒𝑟 𝐶𝑜𝑛𝑡𝑟𝑜𝑙 𝐿𝑖𝑚𝑖𝑡) = 𝑥 − 3𝜎𝑥
- 13. Service Failure Rate Metric 13 Service Failure Rate is the probability of a service's HTTP response failure. 𝑓𝑎𝑖𝑙𝑢𝑟𝑒𝑅𝑎𝑡𝑒 S, 𝑅 = 𝑖 𝑠𝑡𝑎𝑡𝑢𝑠𝑅𝑎𝑡𝑖𝑜 𝑠𝑡𝑖, 𝑅 , 𝑠𝑡 ≥ 400.
- 14. Delayed Response Ratio Metric 14 Delayed Response Ratio is the ratio of the service's excessive response time in multiple responses. 𝐶𝐿 𝑆, 𝑅 = 𝑎𝑣𝑒𝑟𝑎𝑔𝑒𝐷𝑢𝑟𝑎𝑡𝑖𝑜𝑛 𝑆, 𝑅 𝑈𝐶𝐿 𝑆, 𝑅 = 𝐶𝐿 𝑆, 𝑅 + 3 𝐶𝐿 𝑆, 𝑅 𝐷𝑒𝑙𝑎𝑦𝑒𝑑𝑅𝑒𝑠𝑝𝑜𝑛𝑠𝑒𝑅𝑎𝑡𝑖𝑜 𝑆, 𝑅 = 𝑅 𝑑𝑟 𝑅
- 15. Service Usage Metric 15 The Service Usage Metric is the extent to which the service is used within the time interval. 𝑓𝑟𝑒𝑠ℎ 𝑟, 𝑇 = 𝑡 𝑟−𝑡 𝑠𝑡𝑎𝑟𝑡 𝑡 𝑒𝑛𝑑−𝑡 𝑠𝑡𝑎𝑟𝑡 𝑢𝑠𝑎𝑔𝑒 𝑆, 𝑇 = 𝑖 𝑓𝑟𝑒𝑠ℎ 𝑟𝑖, 𝑇 𝐶𝐿 𝑆, 𝑇 = 𝛴𝑖 𝑢𝑠𝑎𝑔𝑒(𝑆 𝑖,𝑇) |𝑆| 𝐿𝐶𝐿 𝑆, 𝑇 = 𝐶𝐿 𝑆, 𝑇 − 3 𝐶𝐿 𝑆, 𝑇
- 16. Other Service Metrics Service Response Status metric The number and proportion of various response statuses of the service in multiple responses. Service Internal Error metric The number of internal execution errors that the service has experienced within the time interval. Service Average Response Duration The average of the time it takes for the service to be in multiple responses, from receiving a request to sending a response. 16
- 17. 17 Architecture of microservice-based system for a cinema
- 18. 18 Detailed service dependency graph related to cinema system
- 19. Demo video 19
- 21. 1. Service Anomalies and Old Patch Version Detection 21
- 22. 22 Service failure rate of payment service
- 23. 23 Delayed response of payment service
- 24. 24 Old Patch Version Detection 1. Correct service anomalies 2. Update the patch version 3. Release the new version of service 4. Detected by the system
- 25. 2. Detecting Low-usage Service Versions for Service Updating 25
- 26. SPC control chart showing usage of payment services prior to transfer of traffic 26
- 27. 27 SPC control chart showing usage of payment service following transfer of traffic
- 28. Conclusion1 28 The features of the proposed scheme are as follows: 1) VMAMV can visualize the dependencies between microservices with multiple versions. 2) VMAMV can identify dependency relationships and patch versions. 3) VMAMV automates the detection of null dependency and incorrect version dependency.
- 29. Conclusion2 29 4) VMAMV monitors the microservice operation and discovers service failures continuously based on the proposed metrics. 5) VMAMV helps users in updating the microservice version by detecting the usages of all versions.
- 30. 30 THANKS! Any questions? You can find me at 10757010@mail.ntou.edu.tw
Editor's Notes
- Good afternoon every one. I am Chun-Yu Chen from National Taiwan Ocean University. Today I am going to introduce our research with you. The topic is Version-based Microservice Analysis, Monitoring, and Visualization. This paper presents a tool for monitoring microservice systems and generating visualized version-based service dependency graphs. (providing monitoring services.)
- Before discussing the microservice architecture, we must understand how this architecture differs from the traditional monolithic architecture. In a monolithic architecture, the entire application is built as a single unit that contains all the business logics. But microservice is different. In the microservice architecture, the business logic is organized as multiple loosely coupled services. And the functionality reuse and scalability are two main features of microservice.
- It is common that a microservice system has hundreds to thousands of microservices. These services are communicated with each other. Furthermore, highly dependent microservice system may undergo expansion such as the release of new versions. It becomes the problem of "Dependency Hell".
- Based on the above analysis, we have identified several challenges. Challenge1 is to clarify and control dependencies between services and versions. As just mentioned, Complicated dependency relationships between Microservices and Tracking of Microservice versions are two issues have been emphasized. But the current systems lack a visual overview that includes services, endpoints, and versions.
- Challenge2 is to monitor dynamic distributed systems. Traditional monitoring methods are poorly suited to systems comprising microservices. As Challenge 1 said, we already have a visual overview. But even if we have it, we would like to know the current status of the service. The existing tools cannot provide this type of information. (Developers will want to know the status of service development, but existing tools cannot do this.)
- And then, Challenge3 is to detect anomalous microservices. Each microservice has specific logics and responsibilities. So, it is normal for services to differ in terms of metric behavior. In general, using any single measurement standard for the detection of all types of service anomaly would be unworkable. We need the proper tools for anomaly detection. https://www.flaticon.com/free-icons/warning
- In response to the previous challenges, we propose a new system, VMAMV, with five features: First the system will scan the codes and parse the document for the visualization where the first feature and the second feature correspond to Challenge 1. And then, when there is a service updating, the status will be monitored by our system. There would be a notification if any anomaly detected by the system. These correspond to Challenge 2 and Challenge 3.
- And this is our system architecture. The system is roughly divided into several parts: VMAMVS, MCA and SRR. They provide the features mentioned above.
- As just discussed, we suggest that developers should apply Semantic Versioning. It can be used to resolve the problem of version by imposing simple rules that limit the configuration and growth of version numbers. There are three versions in rules and each version corresponds to a different situation.
- If developers apply Semantic Versioning, they should follow the development rules to remove the outdated version of service. To help developers manage versions well, our system will highlight the services in improper versions and notice the developers to remove them. This is called New and Old Patch Version Service. The detailed information will be illustrated later.
- Another situation is Null Dependency. It means that a node which does not exist in the system is still dependent and the node is called a null node. Our system can detect this anomaly and show the visual graph for the users. ( When an event that may cause the null dependency occurs (e.g., a service startup or shutdown), VMAMVS determines whether there is a null dependency in the scope of the event. The null node is removed when other nodes no longer depend on it. When it reappears in the system, the previously null node is restored as a normal node. ) ( Because there is a problem with the version, you can provide some abnormal metrics for the user's reference, and decide whether to remove the old version. )
- Next, For visualization of detected anomalies of services in all versions, we used a quality control method, statistical process control. It is a quality control method and it can detect anomalies shortly after they occur. And the control charts are used to determine whether the quality of an item meets specifications. There are three lines in the control chart: CL, UCL and LCL. If the sample value is higher than UCL or lower than LCL, it's seemed abnormal. (CL is the center line and represents the average value. UCL and LCL are the upper and lower control limit and they're both three standard deviations from CL.) ( UCL is the upper control limit and represents the average value plus three times the standard deviation of the average value; LCL is the lower control limit and represents the average value minus the standard deviation of the average. )
- To monitor the Microservices and detect anomalies , we design some metrics. Service Failure Rate is the probability of a service's HTTP response failure. By this metric, users can know whether the responses go wrong frequently. (The failure means that the status codes are greater or equal to four hundred. For example, four hundred and three or four hundred and four.)
- Next metric, Delayed Response Ratio is the ratio of the service's excessive response time in multiple responses. By this metric, users can know whether the response time is normal or not. ( In this figure, the black frame dots are the excessive delays. The delayed response ratio refers to the total number of recorded points divided by the number of recorded points associated with excessive delays. )
- And the Service Usage Metrics is the extent to which the service is used within the time interval. The black frame dot indicates its usage is too low. ( The call indicator usage(S, T) is the sum of the freshness indicators fresh(r, T) of all requests for service S in time interval T. ) ( Determine the C chart based on the SPC method. The judgment threshold is generated by calculating the LCL that calls the metric between versions. A version with a lower metric than the LCL is called a low-usage calling version. )
- There are other service metrics. Details of the above methods and metrics will be demonstrated in our demo video. (like Service Response Status metric, Service Internal Error metric and Service Average Response Duration.) ----------------------------------------------------------------------- (Service Response Status metric The number and proportion of various response statuses of the service in multiple responses. Service Internal Error metric The number of internal execution errors that the service has experienced within the time interval. 𝑖𝑛𝑡𝑒𝑟𝑛𝑎𝑙𝐸𝑟𝑟𝑜𝑟 𝑆,𝑇 = 𝐸 𝑇 Service Average Response Duration The average of the time it takes for the service to be in multiple responses, from receiving a request to sending a response. 𝑎𝑣𝑒𝑟𝑎𝑔𝑒𝐷𝑢𝑟𝑎𝑡𝑖𝑜𝑛 𝑆,𝑅 = 𝑖 𝑑 𝑖 R )
- Before playing the demo video, I would like to show the illustrative example, Cinema system. There are five microservices in the Cinema system and each microservice has four to five endpoints. (There are five microservices in the Cinema system, such as XXX, YYY, ZZZ)
- And then this is detailed service dependency graph related to Cinema system.
- Now , let ’s take a look at the demo video. https://www.youtube.com/watch?v=4H43jLceDjw&feature=youtu.be
- Now let's talk about case and experiment.
- The first experiment is Service Anomalies and Old Patch Version Detection.
- In this case, we injected faults to specific service. When the experiment began, the failure status rate related to the payment service , increased quickly to 30 percent, which was far higher than the upper control limit. This triggered an alert in our system, indicating that the service failure rate was excessively high. (This figure shows that a notification message is sent when the anomaly is detected. )
- The next anomaly is Delayed Response. Each point represents a response time of service and the red point is an excessive response duration. It also triggered an alert. The alerts shown the previous and this page can effectively help developers to notice highly risky services. (The frame indicates that the value is higher than the Upper Control limit.) ( The figure respectively present SPC control chart for the payment service, in which the horizontal axis indicates the response occurrence time and the vertical axis indicates the response duration. )
- When a developer corrects service anomalies, updates the patch version, and releases the new version of service, the system would detect the old patch version and presents it in the dependency graph. (Developer should remove the outdated version.) (This figure presents the old patch version in the simplified dependency graph, where the yellow box is the problem and the yellow arrow points to the latest patch version.)
- The Second experiment is Detecting Low-usage Service Versions for Service Updating.
- In this case, three versions of the payment service are still running on the system, and the aim is to remove the oldest version. In the experiment , we observe the traffic transfer from the oldest version of the service to newer ones.
- At the end of the transfer, the usage metric was below the lower control limit. So, users can stop the old version of service according to the visualization. (When the transfer began, the usage metric of the oldest version began to drop.)
- Finally, in brief, our system has five main features. First one, VMAMV can visualize the dependencies between microservices with multiple versions. It can identify dependency relationships and patch versions. it automates the detection of null dependency and incorrect version dependency.
- It monitors the microservice operation and discovers service failures continuously based on the proposed metrics. It helps users in updating the microservice version by detecting the usages of all versions.
- Thanks!
- In a computer, after a program, library, or hardware is updated to a newer version, files or systems created with the old version of the program can still be operated or used normally. -------------------------------------- 在電腦中指在一個程式、庫或硬體更新到較新版本後，用舊版本程式建立的文件或系統仍能被正常操作或使用
- It is in systems with particularly tight dependency relationships, a complete redesign of every dependent service is often required to complete an upgrade. ------------------------------------ 在依賴關係特別緊密的系統中，通常需要重新設計每個依賴服務才能完成升級。
- Our future development of this system will focus on monitoring of asynchronous service invocations, establishment of cross-system dependencies for self-contained systems (SCSs), and deployment of our system in large-scale microservice systems.
- Self-contained system (SCS) is a software architecture approach that focuses on a separation of the functionality into many independent systems, making the complete logical system a collaboration of many smaller software systems. https://www.slideshare.net/ewolff/selfcontained-systems-a-different-approach-to-microservices -------- 自包含系統（SCS）是一種軟體架構方法，致力於將功能分離為許多獨立的系統，從而使完整的邏輯系統成為許多較小的軟體系統的協作。
- Supplement: Q: Why can I only monitor the Spring Cloud (Java) system? A: We hope to get the most detailed monitoring data and the ability to achieve automatic discovery services, so it is difficult to be compatible with various languages and frameworks. However, it is still possible to extend compatibility by implementing various client-side libraries. Many monitoring systems, including Appdynamics and New Relic, do this. --------------------------------------------------------- 補充: Q: 為何只能監控 Spring Cloud(Java) 系統 A: 我們希望能盡量取得詳細的監控資料和達成自動發現服務的功能，所以很難做到相容於各種語言跟框架。 但是，還是可以通過實作各種 client 端的 library 去擴充相容性，很多監控系統包括 Appdynamics、New Relic 都是這種作法。
- Supplement: Q: Why use the C chart? A: Because the indicator is called to reflect the degree of usage, one of the influencing factors is the number of requests received. The use of a C chart that ignores the number of sample groups will not offset the influencing factor of the number of requests. ----------------------------------- 補充: Q: 為何使用 C 管制圖? A: 因為調用指標是為了反映使用程度的指標，其中一個影響因素是接收請求的數量。使用無視樣本組數量影響的C 管制圖才不會把請求數量這個影響因素抵銷掉。
- In general, the process will be like this. When the service starts, the MCA will scan it and mark the relationships. And then the information will be recorded in OAS file with json format. Next step, the service will register to Eureka Server, Eureka is a RESTful service open sourced by Netflix, mainly used for registration discovery of services. When service has registered in the Eureka Server, Eureka will detect the event and register the service to VMAMVS. The VMAMVS provides three main capabilities, Monitoring , Notification and Visualization. The VMAMVS uses a quality control method for Visualization.
- The process proceeds in the following order: 1. Identify all versions of the service in the service dependency graph. 2. Convert all version strings to version codes. For example, if the version string is zero point zero point one hyphen release, then the version code should be expressed to [0, 0, 1]. [major version, minor version, patch version]
- Find the version with the same two digits (major and minor version) of the version code of the starting node, where the third digit (patch version) is the largest. Compare the version of the starting node to the latest patch version. If the patch version number of the former is smaller than that of the latter, then the new patch version is found; //otherwise, the patch version is found. ----------------------------------------- 找出與搜尋起點的主版號、次版號相同，且修訂號最大的其它版本。 比較搜尋起點的修訂號及除了搜尋起點外最大的修訂號，若前者小於後者則發現新版修訂號，反之則發現舊版修訂號。
- VMAMVS checks for null dependencies each time the service dependency graph is updated. The following is the check performed: Check if the online new service depends on the node that does not exist, and if so, add an null node. Check if the online new service can replace the null node in the system, and if so, remove the null node. Check whether the offline old service is dependent on other nodes and cannot be replaced. If so, add an null node. Check if the null node is no longer dependent, and if so remove the null node. ---------------------------------------------------------------------- 當某個被依賴的節點不存在於系統中，且不可被其它節點替代，則此情形稱為空依賴，此節點即為空節點。 VMAMVS 在每次更新服務相依圖時檢查空依賴，以下是所進行的檢查： 檢查上線的新服務是否依賴了不存在的節點，若是則新增空節點。 檢查上線的新服務是否能替代系統中的空節點，若是則移除空節點。 檢查下線的舊服務是否被其它節點依賴，且不可被取代，若是則新增空節點。 檢查空節點是否已經不再被依賴，若是則移除空節點。
- Eureka: a widely used microservice discovery tool
- MOB is a bridge between the VMAMVS and the monitored object and consists of two components: Registry Controller: Responsible for accepting registration and deregistration requests from the service registry. Service REST API: Provides an interface within VMAMVS for performing REST operations on monitored objects. --------------------------------------------------------- MOB 是連結 VMAMVS 與監控對象間的橋接器，由兩個元件組成： Registry Controller: 負責接受來自服務註冊中心的註冊及註銷請求，註冊資料以節點形式儲存在圖資料庫裡。 Service REST API: 通過向已註冊的服務註冊中心請求服務資訊來發現服務，並銜接 VMAMVS 內部與受監控服務的溝通。
- The dependent graph module is the module in VMAMVS that is responsible for processing the related logic of the dependent graph. It consists of two components: Dependency Graph Service: Responsible for the construction, maintenance, and search of dependent graphs. Dependency Graph Analyzer: Responsible for dependent errors or potential problem detection, used by Dependency Graph Service. We use a variety of methods in the Dependency Graph Module to address issues related to service dependencies, followed by a description. -------------------------------------------- Dependency Graph Module 是 VMAMVS 中負責處理相依圖相關邏輯的模組，由兩個元件組成： Dependency Graph Service: 負責相依圖的建構、維護、搜尋。 Dependency Graph Analyzer: 負責相依錯誤或潛在問題檢測，被Dependency Graph Service使用。 我們在 Dependency Graph Module 裡使用了多種方法解決跟服務相依有關的議題，接下來依序說明。
- The monitoring module is the module responsible for processing the monitoring related logic in VMAMVS. It consists of three components: Monitor Service: This is responsible for the main logic of monitoring in which metrics are used to detect anomalies. Service Rest Info Analyzer: This converts information obtained from information endpoints into metrics for use by the monitor service. Service Log Analyzer: This converts the service log into metrics for use by monitor service . --------------------------------------- 監控模組是 VMAMVS 中負責處理監控相關邏輯的模組，由三個元件組成： Monitor Service: 負責監控的主要邏輯，使用指標來檢測問題。 Service Rest Info Analyzer: 負責將從資訊端點取得的資訊轉換成指標，被Monitor Service使用。 Service Log Analyzer: 負責將服務日誌 (Log) 資訊轉換成指標，被Monitor Service使用。
- VMAMVS is the core of the system in charge of logic and data, and communicates with the services of the monitored system to obtain service dependency information and monitoring data. In the storage of data: The service logs of the monitored system are collected and filtered by the Log Processing Pipeline and then transferred to the Service Log Database. The Service Log Database will be used by VMAMVS as a repository for storing logs and a search engine. Information such as service dependency graphs and monitoring settings are stored in the Graph Database. VMAMVS contains 12 main components, which can be divided into three major modules: Monitoring Object Bridge, Dependency Graph Module, and Monitor Module. ----------------------------- VMAMVS 是系統中掌管邏輯與資料的核心，對外與被監控系統的服務溝通，以取得服務的依賴關係資訊和監控資料。 在資料的儲存上: 受監控系統的服務日誌通過 Log Processing Pipeline 進行收集與過濾，然後傳送到 Service Log Database。Service Log Database 會做為儲存日誌的資料庫和搜尋引擎被 VMAMVS 使用。 服務相依圖與監控設定等資料則儲存於 Graph Database。 VMAMVS 內部包含12個主要元件，可劃分為3大模組，分別是：Monitoring Object Bridge、Dependency Graph Module、Monitor Module
- 基於服務表與擴充OAS文件的服務相依圖建立與維護 VMAMV 服務相依圖的建立及更新大致流程： 向已註冊之服務註冊中心取得服務實例表。 向服務實例取得版本資訊，並建立出包含版本資訊的受監控系統服務表。 比較 VMAMV 現有的服務表及新的服務表。 依據服務表的差異，向服務取得擴充OAS文件，並更新服務相依圖。 若更新了相依圖，則產生相依圖資料暫存於VMAMVS。 Obtain a service instance form from the registered service registry. Get version information from the service instance and create a monitored system service table containing version information. Compare VMAMVS' existing service tables with new service tables. According to the difference of the service table, the extended OAS file is obtained from the service, and the service dependency graph is updated. If the dependent graph is updated, the dependent graph data is temporarily stored in VMAMVS.
- 基於服務表與擴充OAS文件的服務相依圖建立與維護 VMAMV 服務相依圖的建立及更新大致流程： 向已註冊之服務註冊中心取得服務實例表。 向服務實例取得版本資訊，並建立出包含版本資訊的受監控系統服務表。 比較 VMAMV 現有的服務表及新的服務表。 依據服務表的差異，向服務取得擴充OAS文件，並更新服務相依圖。 若更新了相依圖，則產生相依圖資料暫存於VMAMVS。 Obtain a service instance form from the registered service registry. Get version information from the service instance and create a monitored system service table containing version information. Compare VMAMVS' existing service tables with new service tables. According to the difference of the service table, the extended OAS file is obtained from the service, and the service dependency graph is updated. If the dependent graph is updated, the dependent graph data is temporarily stored in VMAMVS.
- 基於圖之消費者搜尋 VMAMV 提供消費者搜尋，可以找出特定節點的使用者。 左邊是方法示意圖，流程很簡單: 搜尋起點 (START) 可以是服務 (Service)、端點 (Endpoint)或訊息列隊 (Queue)。 從 (START) 向外搜尋，尋找與 (START) 間符合右側關係的節點 (Cn)。 {C1, C2, C3, C4, C5} 即為消費者節點的集合。
- 基於圖之提供者搜尋 VMAMV also has a provider search that can find the nodes used by a particular node. The method is basically the same as the previous consumer search, but the opposite is true. VMAMV 也有提供者搜尋，可以找出特定節點的所使用的節點。 方法和前面的消費者搜尋基本相同，只是關係相反。
- The service response failure rate failureRate(S,R) statusRatio(st,R) is the ratio of the number of responses with a status code of st to the number of all responses in multiple responses R. failureRate(S,R) has a value between 0 and 1, representing the proportion of service S failures in multiple responses R, which is the sum of statusRatio(st,R) for all failure states (status code ≥400) --------------------------------------- 接下來講一些重要指標 服務回應錯誤率是服務的 HTTP 回應失敗機率： 要計算回應錯誤率，必需先得出在多個回應裡特定狀態碼的回應占所有回應數量的比例。 將所有失敗狀態的回應所佔的比例相加就能得出回應錯誤率。
- A low-usage service version indicates that a particular version of the service is being used to a much lesser extent than other versions. Determine the C chart based on the SPC method. The judgment threshold is generated by calculating the LCL that calls the metric between versions. A version with a lower metric than the LCL is called a low-usage calling version. Supplement: Q: Why use the C chart? A: Because the indicator is called to reflect the degree of usage, one of the influencing factors is the number of requests received. The use of a C chart that ignores the number of sample groups will not offset the influencing factor of the number of requests. ----------------------------------- 低比例調用版本判斷 低比例調用版本表示服務的特定版本被使用的程度明顯低於其它版本。 判斷基於 SPC 方法的 C 管制圖。 通過計算各版本間調用指標的 LCL 來產生判斷閥值。 調用指標低於 LCL 的版本即判斷為低比例調用版本。 補充: Q: 為何使用 C 管制圖? A: 因為調用指標是為了反映使用程度的指標，其中一個影響因素是接收請求的數量。使用無視樣本組數量影響的C 管制圖才不會把請求數量這個影響因素抵銷掉。
- Functionality reuse、Data management、Deployment、Scalability、Communication within the application Functionality reuse： ※ Microservices define APIs that expose their functionality to any client. The clients could even be other applications. Data management： ※ Decentralized: Each microservice may use its own database. Deployment： ※ Each microservice is deployed independently, without affecting the other microservices in the application. Scalability： ※ The modularity of microservices enhances fault tolerance and scalability; Communication within the application： ※ To communicate with each other, the microservices of an application use the request-response communication model. The typical implementation uses REST API calls based on the HTTP protocol.