Create a microservices service? Please answer these 10 questions first

Original Address: http://mp.weixin.qq.com/s?__biz=MzA5OTAyNzQ2OA==&mid=401654497&idx=1&sn= 5cac9aa4ae113592e1513c1ff70ea917&scene=21#wechat_redirect

At first glance MicroServices seem to be easy to build, but to really build microservices, the work done is much more than running some code in the container and using HTTP requests to communicate between the code. Before you can develop a new microservices-you have to answer these 10 important questions before you deploy the new service to the production environment.

1. How do I test the service?

Micro-services have some advantages and disadvantages when considering testing. On the one hand, a well-defined unit of small-scale services with a small segment of functionality is much easier to test than the entire large application. On the other hand, validating the quality of an entire application consisting of many microservices is bound to significantly increase the complexity of testing: You cannot run a single command to test code in a process, and a large number of integrated interdependent components must be run first to verify their health and to keep them running during testing.

Will the new microservices be tested in an "integrated" or "staging" environment that is closer to real-world use, with both isolation testing (using unit testing or simulation dependencies) and connecting to services that are actually connected in some production environments? Does the test combine performance validation and error modes? Will all tests be automated, or will it require the operation of human intervention tests and the viewing of test results? For microservices to be easy, fast, and automated, this encourages developers to maintain tests and avoid "broken windows" issues.

2. How do I configure the service?

How can the internal behavior of new microservices be impacted once they are deployed in a production environment? This includes infrastructure changes (for example, changing the minimum number of processes in a resource pool), and some application-level changes (for example, by triggering a feature flag to start a new feature). For all of these changes, it is important to focus on the need to restart the service for these changes to take effect.

3. How do other parts of the system use the service?

Unless other components of the system really need to use a service, it is necessary to build it, so it is important to understand how they will use the service.

is the interaction between the other components and the new service synchronous or asynchronous? Do you encourage them to cache responses from this service? How do I retry and guarantee the power of the result? Does the SLA for the new MicroServices online time match the other components of the system?

The response latency that this new microservices can provide needs to be clearly defined, and the components that invoke the service must know these metrics. Thus, when these metrics are not met, other parts of the system can decide to issue a timeout signal, interrupt the current operation, or go to another instance of the service.

4. How do I protect this service?

Unless in a highly secure environment, most microservices deployed behind firewalls do not need to worry too much about security within the service. Adding a large number of security checks between microservices can create significant operational complexity and make production environment problems more difficult to debug and repair. Even https that uses HTTP over intra-service communications can cause significant maintenance overhead due to the need for maintenance, deployment, and protection of some correctly signed certificates.

The common scenario is to allow traffic to flow across microservices, while using application-level authorization and authentication to ensure application-level security.

Therefore, other components in the system should be able to send requests to the microservices, but may still need to pass some authentication data at the same time, which represents the original external user of the request that was actually approved. These data can never be plaintext cipher data, using techniques such as JWT,OAUTH,SAML and Auth0. Whichever scenario you use requires a clear record of the technology used, preferably in the client library or in the sample code, making it easy for other developers to use the new microservices.

5. How do I discover services?

How do other components in the system find it when the new microservices are started? The simpler the process of discovering a service, the less likely it is to be complex, but the more problems you will face later. For example, the simplest method (and, of course, error prone) is to hardcode the address of the microservices in other component code or configurations that depend on the service. This does work until the service address changes, or until multiple instances of the service are started in other domains. This is obviously not the recommended way.

Using indirect techniques, such as DNS names, can better hide the address of a microservices, but there are drawbacks to this scenario: finding a suitable TTL value, forcing redo name resolution, ensuring that the DNS cache behaves consistently, and so on. From a design perspective, DNS does not take into account the availability of the service, which causes the application's components to send requests to an unattended IP address, which can be a waste of time and interfere with actual operations by trying to find an instance that works. This also makes the developer experience very bad, because using DNS as a routing mechanism often results in developers needing to modify their/etc/hosts files frequently.

In the most complex scenarios, highly available databases and data synchronization services (such as zookeeper) may be used as registries for currently available and well-functioning microservices. Such a scenario requires more technology investment and is handled with care to ensure that the discovery service itself does not become a point of failure (single point of Failure,spof). When a microservices is started, it registers itself with such a registration service, and it removes itself when the microservices are closed. If the microservices are terminated unexpectedly or are deadlocked, they are automatically removed from the registry. Remember that discovering services is not just about finding what's running-it's also important to know what's not.

6. How does the service scale when the load is increased?

If a microservices is really valuable in the application, the number of developers who use them will grow, and as the usage grows, traffic will soar. The new microservices have well-designed expansion plans that are important to the operations team.

Can microservices be expanded automatically? Is there a state that resides in memory, which makes auto-scaling and request routing difficult (for example, user session state)? If so, what is the partitioning strategy?

It would be useful to know in advance which part of the microservices is going to go wrong first when it is massively expanded. For services supported by the database, computing power (for example, EC2 instances in an auto-scaling group) can often be extended continuously until the database is overwhelmed. For a truly stateless service (for example, a computational microservices that does not read from the database and not write), the first problem may be the load balancer that precedes the instance cluster. There are solutions for both cases, but these scenarios do not necessarily need to be in place when the first version of the microservices is deployed. However, there is a need to learn more about the limitations of the new microservices in order to know where the service's extended ceilings are before the production environment can reach its maximum capacity.

7. How does the service handle its dependency errors?

Even if the scope of the microservices is very small, it may also depend on other services or monolith programs already in the system. For example, most application transactions require a view of customer information, so the services used to access customer records are often dependent on most services that provide business value.

If the new microservices depend on any other services, what happens when these dependent services fail is critical. Using a fixed request time-out is a good start, but adding a process breakpoint might be better. The owner of the service you rely on should also want its users to avoid jingzhe problems by using techniques like exponential delay when a failure occurs.

This scenario is a good test because its tests only require that the services it relies on are not available. However, it is important to remember that the invocation of the service API that you depend on fails for many reasons, and that the performance of these failures can vary.

8. How do other parts of the system handle the failure of the new service?

Depending on how much you invest in the high availability of the new microservices and what kind of transactions they support, this may not be an important issue. For example, a simple operations log microservices, which asynchronously sends data over UDP, can occur for several minutes, but this has no effect on the primary business transaction of the application. However, if a micro-service that asynchronously handles credit card transactions fails, it can severely damage the e-commerce system, and the failure scenario must be rigorously tested and prepared for the response.

Therefore, even if a limited range of microservices (or their developers) do not need to worry about how the new component is used by other parts of the system, the system-level considerations about how each service relies on other services can help avoid cascading failures and help ensure the overall performance of the application.

9. How is the service upgraded?

There may be a tendency to think of container technology such as Docker, and the deployment automation tools such as ansible make upgrades less important, but the maintenance of microservices needs to take into account many other aspects of the existing tools that cannot be solved.

It is important to define the upgrade strategy and determine the level of deployment complexity that MicroServices supports. When you want to replace the old version with the new version, the Canary test, the blue/green deployment, the feature flags, and the response diff ' ing these, require more time and effort than a simple rolling upgrade.

defining boundaries and policies for the upgrade of MicroServices APIs is more important for components that depend on them. For example, a JSON schema that allows only one API at a time adds a change, which allows the service to continue to improve and does not require its users to be upgraded every time. However, adding a new field to the XML response payload can cause serious problems if the user does XML schema validation every time. So if you regularly upgrade new microservices and add more and more fields to their API objects, you need to keep a clear record of the users of their services in their documents.

Finally, learn how microservices roll back if a new version is problematic, and how to consider rollback metrics.

10. How do I monitor and measure services?

If your company already has standards for application monitoring, you should use these standards, with existing monitoring ecosystems. Be careful not to ignore existing standards-or, more seriously-to use new monitoring tools and to operate the team before they are completely unused.

If your company does not yet have a high-quality application monitoring system, adding new microservices to your application can be a starting point for building a monitoring system. This is especially important for businesses that have previously been monitoring large monolithic applications, and are now starting to migrate to MicroServices architectures: the operational monitoring requirements of a series of interconnected microservices are much more complex than the monitoring requirements of a single large monolith program.

Regardless of which monitoring option you choose, whether you are developing it yourself, choosing open source or commercial software, developers of microservices apply monitoring and measurement data that fully accesses their components. Without such transparency, a complete feedback loop cannot be implemented, and developers will not know how to improve their services in a production environment or help diagnose problems quickly when they occur.

Summarize

There is no need to have a particularly detailed answer to each of the 10 questions above, but every point needs to be considered and the architectural constraints that microservices may bring. For example, the start of a new microservices deployment may not take into account disaster preparedness and domain failure tolerance, and then upgrade to include such capabilities. Understanding what the microservices can do and what they can't do is critical, and thinking about the answers to these questions can help keep improving services and eventually evolve into mature, resilient, and reliable system components.

Create a microservices service? Please answer these 10 questions first