Micro Modular or service?
Our business shift from a large-scale application of micro-services, apart pretty good show PPT, enhance KPI addition, the actual operation will cut mini entire business service seems effortless. However, this method is really our best choice? Indeed, the maintenance messy monolithic applications have a number of disadvantages. But there is a compelling alternative to often overlooked: a modular application development. In this article, we will explore the implications of this alternative, and show its relationship to build micro-services.
What is micro-services?
Micro services are now more and more popular, but in the end what is micro service? Sam Newman provides a succinct definition of micro services is "Building Micro Services":. "Micro-services is a small, self-service, and between each other can work together."
In the "micro Services Architecture," this book, the author Mike Amundsen, Irakli Nadareishvili, Ronnie Mitra and Matt McLarty shared by the survey of the service application features details of Micro services:
- small volume
- Enable message
- Context-bound
- Self development
- Can be deployed independently
- dispersion
- Using automated build and release processes
A modular micro-services
"Through micro-services, we can make the final team to work independently," or "our application is too complex, it slows us down." These expressions are merely lead to the development team took a small part of the many reasons the service road in the micro. Another problem is the need for scalability and flexibility. Developers always seem to want is a modular approach to system design and development.
The modular software development can be attributed to three guiding principles:
1.1, a powerful package
Internal implementation details hidden components, resulting in low coupling between different components. Teams can work independently on a separate part of the system.
1.2 Good define the interface
You can not hide all the content (or your system will not do anything meaningful), thus defining the components between good and stable API is a must. Compliance may be implemented by any component interface specification replaced.
1.3, explicit dependencies
The modular system means have different components must work together. You better have an expression (and verify) a good way of their relationship.
The above principles can be achieved through micro-services. The micro-services can use any manner, as long as it is publicly well-defined interfaces for other services (usually the REST API) can be. Its internal implementation details are details of the service, it can be changed without affecting system-wide coordination or case. But micro-dependencies between services are often not very clear at the time of development, it may lead to runtime service orchestration fails.
Therefore, the micro service implements the important principle of modularity, which brings tangible benefits:
- Teams can work independently and expansion.
- Micro-service small-scale, focused and reduced complexity.
- Service can be changed or replaced in-house, without creating a global impact.
As we transition from one (though a bit bloated) applications for distributed micro-services system, which actually brought a lot of operational complexity. Suddenly, you will need to continue to deploy a number of different (possibly containerized) service. The emergence of new problems: service discovery, distributed logging, tracking and so on. Now more error prone in the distributed computing. Version control and configuration management interfaces will also become a major problem. And the list of issues will always grow it.
The fact that, as a complex combination of logical connections between the micro-business services with all single micro-services. Although there is a problem in the overall code base "spaghetti code," but there is a network boundary issues make these entangled upgraded to downright pain in between.
ps: spaghetti code that is unstructured and difficult to maintain source code derogatory term. It can be caused by many factors, such as variable project requirements, lack of programming style rule and lack of ability or experience.
Second, an alternative modular
Does this mean that we either be downgraded to messy large applications, or to be drowned in the madness of the complexity of the micro-services ? The modular can also be achieved by other means. Important is that we can effectively draw and enforce boundaries in the development process. But we can also achieve this by creating a well-structured large-scale application. Of course, this means that we tend to get help from a programming language and development tools to implement a modular principle.
For example, in Java, there are several modules of the system can help you build applications. OSGi is a most famous name, but with the release of Java 9, the Java platform itself will add a native module system. This feature module as a first-class structure is now part of the language and platform. Java module can express dependencies on other modules, and at the same time powerful disclosed export interface implementation class packaged. Even Java platform itself (a large code base) are also using the new Java module system is modular.
Other languages provide similar mechanisms. For example, JavaScript began to gain a module system from ES2015. Prior to this, Node.js module system has provided a non-standard JavaScript as the back-end. However, as a dynamic language, JavaScript support for the embodiment of the package between the interface (Type) and the module is weak. This advantage can be considered to get used again TypeScript on JavaScript. Microsoft's .Net Framework does strongly typed Java-like, but it is not directly equivalent to a modular system in Java upcoming explicit dependency between the powerful aspects of packaging and assembly. Nevertheless, by using a standardized in the .Net Core Inversion-of-Control mode, and by creating a set of associated logic, we can achieve a good modular architecture. Even C ++ is also considering adding a module system in future versions. Many languages are increasingly interested in modular, modular itself is a striking development.
When we use modular development platform function consciously, you can achieve our previously attributed to the service of the same micro-modular advantage. In essence, modular system, the better, the more available to help in the development process. Different teams can work on different parts of the interface where the contact point between the teams is only clearly defined. However, at the time of deployment, the module together in a deployment unit. In this way, you can prevent migration of the substance related to the complexity and cost of service development and micro management. Of course, this means you can not build each module on a different technology stack, but for most companies and development team, really good control of multiple technology stacks?
Third, the design module
Creating good module needs to create a good micro-serving the same design requirements. Single module should simulate business domain bounded context. Select the service boundary is on a micro architecture important decisions, if wrong, it will have costly consequences. The module boundaries modular applications easier to change. Type system and compiler usually supports reconstruction across modules. Redrawing the boundaries micro-services requires a lot of interpersonal communication, in order to avoid an explosion at runtime.
In many ways, a statically typed language modules provide a better structure for the well-defined interfaces. Type of interface calls the method disclosed by another module to change than calling REST endpoints on another micro-services much stronger. REST + JSON everywhere, but in the absence (compiler checks) mode, it is not good interoperability flag type. More importantly, many modular system allows the expression of dependencies on other modules, when in violation of these dependencies, the module will be prohibited from doing so, at least there will be a clear hint, but the dependencies between micro-only service running when implementing, causing the system difficult to debug.
The code module is the natural unit of ownership. Team may be responsible for one or more modules in the system. The only thing to share with other teams is its modular public API. In operation, as compared with micro-services, less isolation between modules. After all, everything is still running in the same process.
There is no reason why the single-block modules can not have it like that's a good micro-data service. Then, in the shared application may be well-defined modular interfaces or through the messages between the modules, instead of the shared data storage area. The biggest difference is that all the micro-services are in progress. The final consistency should not be underestimated. By module final consistency may be a deliberate strategic choice, rather than the inevitable choice. For micro-services, there is no choice: only choose the final consistency.
Fourth, the micro-service when it is appropriate for your organization?
So when you should turn to micro-services ? So far, we have primarily focused on solving complex problems through modularity. To this end, micro-services and modular applications can be. But in addition to the challenges presented to date, there are different challenges.
-
When the company has the scale of Google or Netflix, and every reason to accept the micro-services . This means that the ability to build their own platform and tool kit, and the number of engineers have been enough. But most organizations do not operate in this size. Even if the company would one day be worth one billion US dollars of the Unicorn, from the beginning of large-scale modular application will not cause any problems.
-
Another good reason to start a separate micro service is the nature of the different services better suited to a different technology stack . That is a lock, you must have sufficient size to attract these people different technologies stack, and maintain the normal operation of these platforms.
-
Micro services can also be deployed independently in different parts of the system, it is difficult (if not impossible) for most modular platform . Isolation deployment increases the flexibility and fault tolerance of the system. In addition, each micro-zoom feature for service may be different. Different micro-services can be deployed to match the hardware. The overall level of modularity can be scaled, but more subtle is very difficult. But in general practice, this modular way to support business development for a long time.
V. Conclusion
how to choose? In fact, depending on the environment, the organization and the application itself . We can start from modular applications, then feel free to choose to transfer to the micro-service module can also be used to build micro-service in-house.
If we pursue the benefits of modularity, make sure we do not fall into the micro can only use the service mode of thinking. As far as possible in the favorite or most adept technology stack using the built-in function or modular framework.
Author: Mark enjoy school classroom
Please indicate the source.
I continue to focus, to share more dry.
Reproduced in: https: //juejin.im/post/5d0b55dc6fb9a07efe2dc316