microservices have and have only a very specific feature that provides the rest of the system through remote APIs. For example: Imagine a warehouse management system in which microservices may provide some of the features:
- Receiving inventory
- Calculate where the new inventory should be stored
- Calculate the route where the inventory is shipped to the correct point of placement within the warehouse
- Assigning shipping routes to warehouse employees
- Receiving orders
- Calculates a picking route for a specified set of orders within a warehouse
- Assign picking routes to warehouse employees
these features (and possibly more) are implemented by a single microservices. Each micro-service has a separate running thread and can be deployed independently of other microservices. Similarly, each microservices has its own dedicated database, although each micro-service will collaborate and communicate with other microservices.
the different microservices in a system are entirely possible to implement on different platforms, some of which may be in. NET, some in Erlang, others on node. js. As long as you can coordinate the multi-lingual problem, each micro-service can communicate with each other and it will work. HTTP is a good communication option: all of the platforms mentioned above, and many other platforms, can handle HTTP very well. There are also other technologies that meet the microservices communication rules: for example, some queues, some service buses, and some binary protocols. Of these technologies, HTTP may be the most widely supported, fairly easy to understand, and as useful as the World Wide Web shows, it's a good solution in general.
again take the warehouse system as an example: the system of a micro-service is to assign pick Route microservices. Figure one shows the request that the assign pick Route microservices receives from another collaboration microservices: Sets the next pick route for the specified employee. Assigned pick Line MicroServices must find the right route for the employee, while the other microservices complete the work of calculating the best route, and assigning a pick route microservices only receives the pick route notification and determines how the route is assigned to the employee. In the microservices that assign the pick route, you receive the request-assign the selected employee's pick route, search the database, find the appropriate pick route, and choose one from which to return to the microservices call.
What is a microservices architecture?
microservices are a type of architecture that is a lightweight, service-oriented architecture that is strictly focused on doing the same thing and doing it well.
A system that uses microservices as the primary architecture type is a distributed system with a large number of coordinated microservices, each of which is in charge of its own processes. Because of the close collaboration between MicroServices, each micro-service only provides a small piece of the puzzle, and the system works as a complete work. When collaborating, services communicate with each other through a lightweight medium that is not tied to a specific platform, such as. Net,java or Erlang. As mentioned earlier, all of the microservices in this book are communicated via HTTP, but there are other options, such as queues, buses, or binary protocols like thrift.
the type of microservices architecture is rapidly prevalent when building and maintaining complex server-side software systems. As you can imagine, there are a number of potential benefits to microservices in the traditional service-oriented approach and overall architecture (monolithic architectures). In a well-functioning environment, microservices have an advantage in terms of plasticity, scalability and resiliency, and allow users to deploy from start to production in a very short time.
Micro-service features
Although it has been said so much, but the definition is still very vague. To narrow down the scope of microservices, let's look at the features of MicroServices first. In the author's understanding, the characteristics of the term microservices are:
1. Responsible for individual functions
2. Standalone Deployment
3. Include one or more processes
4. Have your own data storage
5. A small team can maintain several microservices
6. replaceable
This list of features not only helps identify microservices, but also assists in defining and executing the service, in turn, by providing a micro-service advantage (a system that is malleable, scalable and resilient).
responsible for individual functions
MicroServices are only responsible for a single function throughout the system. The decomposition of this sentence consists of two parts: first, the micro-service has only a single responsibility; second, the function is responsible. The single responsibility principle has several descriptions, one of which is traditionally described as:
Reference
"When you need to modify a class, there is only one reason (" There should never is more than a reason for a class-to-change. ") ) "-Robert c. Martin SRP: Single Responsibility Principle
Although this statement specifically mentions "classes", this principle applies not only to the class level of the object-oriented language. Through microservices, the principle of single responsibility is applied at the service level. Another relatively new statement describes the principle of single responsibility:
Reference
An aggregation of things that change for the same reason, separating things that change for different reasons. ("Gather together the Things," for the same reasons. Separate those things the change for different reasons. " )-Robert C. Martin single responsibility Principle
This principle applies to microservices: MicroServices should implement exactly one function. MicroServices must change only when the functionality changes. In addition, efforts should be made to enable microservices to fully implement the relevant functions so that microservices are changed as the functionality changes.
a function of a microservices system may mean a few things. First, the functionality may be business-related. Business functions are things that the system accomplishes and contributes to the purpose of the system-such as keeping track of the user's shopping cart or calculating the price. A good way to comb the independent business functions of a system is to use domain driven Design. Second, sometimes functionality can be a technical feature that multiple other microservices need to leverage-such as integration into some third-party systems. The technical function is not the main cause of the decomposition of the system into microservices, but the result of the same technical capability required by microservices to perform business functions.
Standalone Deployment
each micro-service should be deployed separately. That is, when you change a specific microservices, you need to be able to deploy changes to the microservices into a production environment without having to deploy or touch other parts of the system. In fact, other microservices in the system should continue to run when the modified microservices are deployed and when a new version of the service is deployed.
Imagine e-commerce sites: every time a shopping cart microservices changes, you should be able to deploy immediately. At the same time, the price calculation microservices, recommended microservices, product catalog MicroServices and so on should continue to run and meet the user's request.
It is important to be able to deploy each micro-service separately for several reasons. One of them is that there are a lot of microservices in a microservices system, and each micro-service works with several others. Each part of the development work is done at the same time, or many microservices parallel. If you need to deploy all or many microservices at the same pace, the management deployment will quickly become stretched, especially with high-risk deployments, which we would like to avoid. Instead, we want to be able to deploy small changes to each microservices so that the risk is lower.
The ability to deploy a single microservices while the rest of the system continues to function properly, the build process must keep this in mind: each microservices must be packaged into different artifacts or packages. Similarly, the deployment process itself must also support the need to independently deploy the changed microservices when other microservices continue to run. For example, you can use a rolling deployment approach to reduce downtime every time you deploy MicroServices to a server.
the way microservices interact is also affected by the expected independent deployment. Changing the MicroServices interface must be backwards compatible in most cases, so that other existing microservices can continue to integrate with the new version in a way that blends with the old version. In addition, the way microservices interact must be resilient, and each microservices must continue to operate optimally when other microservices occasionally fail. A microservices error--for example, because of a short outage at deployment time--must not affect other microservices to run, only to reduce functionality or take a little longer.
contains one or more processes
a micro-service consists of one or more processes, and this feature has two sides. First, each micro-service runs independently of the other microservices, and second, each microservices can have more than one process.
a micro-service runs independently because it wants to keep each micro-service running as independent of other microservices as possible. In addition, in order to deploy microservices independently, the microservices cannot run in the same way as other microservices. Another example of shopping cart MicroServices: If running in the same way as the product catalog microservices, the shopping cart code can negatively affect the product catalog code, which represents a tight but unwelcome coupling between the shopping cart microservices and the product catalog microservices.
now consider the new version of the deployment of the shopping cart microservices. Either you have to redeploy the product catalog MicroServices, or you have to have some kind of dynamic code loading to replace the running shopping cart code. The previous option is completely inconsistent with the principle that microservices are deployed independently, and the latter option is too complex and at least at the risk of a product catalog MicroServices outage due to the deployment of a shopping cart microservices service.
each micro-service may contain more than one process, and it may seem surprising that, after all, trying to keep each microservices as simple as possible, why bother to have more than one process? Using an e-commerce Web site to make an analogy: The Executive recommendation algorithm will show the recommended options on the ecommerce site, which runs in the process that the microservices belong to and stores the data that provides the recommended requirements. This data may be stored in a hard disk file, but it is more likely to exist in the database, and the database running in the second process belongs to the microservices. A microservices typically has a requirement of 2 or more processes because microservices need to implement everything they need to provide functionality that includes data storage and background processing.
have your own data store
A microservices contains data stores that store the required data in that process, precisely because we want the scope of the microservices to be a complete feature. Most business functions require some data storage, for example, for product catalog microservices, the information for each product needs to be stored. To maintain the loose coupling between the product catalog MicroServices and other microservices, the stored product information data is fully contained within the product catalog MicroServices. The Product catalog MicroServices determine when and how to store product information. Other microservices-such as shopping cart microservices-access product information only through the interface of the product catalog MicroServices, and never directly access the product catalog storage.
each microservices contains its own data store, which opens up the possibility of using different database technologies for different microservices depending on the needs of each micro-service. Product Catalog microservices may use a SQL Server to store product information, and the shopping cart microservices may use Redis to store information about each user's shopping cart, while the recommended microservices use the elastic search index to provide referral services. The database technology selected for each microservices is part of the execution and is hidden from other microservices. The advantage of mixing database technology with each microservices requirement is that each microservices can use the most appropriate database. It's good for development time, performance, and scalability, but it also brings cost issues. The database is technically very complex, and it is not easy to learn to use and run a reliable database in a production environment. When selecting database information for a microservices service, you should consider the choice of trade-offs. Keep in mind, however, that since microservices have their own data stores, it is also possible to switch to another database later.
small teams are able to maintain
until now, this article does not discuss the scale of too many microservices, although the micro-service "micro" implies that these services are small scale. But there is no point in discussing how a microservices should have several lines of code, how much a demand/use case has, or how many functional points should be performed. All of this depends on the complexity of the functionality provided by MicroServices. What really make sense is to consider the workload of maintaining microservices. One rule of thumb for the size of microservices is that a small team of 5 people should be able to maintain several or more microservices. Maintaining a microservices includes keeping them running and achieving goals: developing new capabilities, breaking new microservices from development to large-scale microservices, monitoring testing and fixing bugs, and more. Given that a small team should be able to do all of the work for several microservices, you should have a concept of typical microservices scale.
can be replaced by
a micro-service is replaceable, which means it can be rewritten from scratch within a reasonable time frame. In other words, the team that maintains the microservices can decide to replace the existing ones with a completely new implementation without disrupting the process of working properly. This feature is also a constraint on the scale of microservices: If a micro-service grows too large, the replacement costs will be too high, and only small can make rewriting more realistic.
Why does the team decide to rewrite the microservices? One reason may be that the code is too messy, and another reason is that microservices do not work well in a production environment. Although these circumstances are not what they wish, they embody the advantages of micro-services. Even if efforts are made to build microservices, changes in the time-to-change requirements may prompt existing implementations to fail to meet demand. And over time, the code may become mess due to too many initial design twists and turns. Performance requirements may require significant improvements, and existing designs cannot be met. If a micro-service is small enough to be rewritten within a reasonable timeframe, the occasional occurrence of these situations is OK. Understanding the existing implementation of all knowledge, combined with new requirements, can simply complete the rewrite work.
[Server architecture] in-depth thinking of microservices
