Problem
1 with Monolithic Applications A simple application grows larger over time. It must be a pain for the development team to become a big and complex monster. Agile development and deployment is difficult because the application is so complex that it is impossible for any single developer to understand it.
2 Monolithic applications also slow down development. The larger the app, the longer the startup time.
3 Complex and huge monolithic applications are also not conducive to continuous development. Continuous deployment can also be tough.
4 Monolithic applications will be very difficult to expand when resources conflict between different modules. For example, a module that implements a CPU-sensitive logic should be deployed in AWS EC2 Compute Optimized instances, while another in-memory database module is more suitable for EC2 Memory-optimized instances. However, since these modules are deployed together, a compromise has to be made in hardware selection.
5 Another problem with monolithic applications is reliability. Because all modules run in one process, a bug in any one module, such as a memory leak, will likely bring down the entire process.
6 Finally, monolithic applications make it difficult to adopt new architectures and languages. For example, imagine you have 2 million lines of code written in the XYZ framework. If you want to change to the ABC framework, both time and cost are very expensive, even if the ABC framework is better.
To sum it up: You start off with a successful business-critical application, and then turn into a giant, incomprehensible monster. Hiring potential developers is difficult because of outdated, inefficient technologies. Applications cannot scale, reliability is low, and ultimately, agile development and deployment becomes impossible.
What is a microservice?
A microservice generally completes a specific function, such as order management, customer management, and so on. Each microservice is a tiny hexagonal application with its own business logic and adapters. Some microservices also publish APIs for use by other microservices and application clients. Other microservices complete a web UI. At runtime, each instance may be a cloud VM or a Docker container.
Each background service exposes a REST API, and many services themselves also use APIs provided by other services.
All services use asynchronous, message-based communication.
Unlike traditional multiple services sharing a database, the microservice architecture has its own database for each service.
Each service has its own database, and each service can use a database type that is more suitable for it, also known as a polyglot consistency architecture.
On the surface, the microservices architecture pattern is a bit like SOA in that they are composed of multiple services. However, to look at this from another angle, the microservices architecture pattern is an SOA without Web Services (WS-) and ESB services. Microservice applications prefer to use simple and lightweight protocols such as REST instead of WS-, avoiding ESB and ESB-like functionality within microservices. The microservices architecture pattern also rejects SOA concepts like canonical schema.
The purpose of microservices is to effectively split applications for agile development and deployment.
Benefits of Microservice Architecture
1 Solve the complexity problem by decomposing huge monolithic application into multiple service approach. A single service is easy to develop, understand, and maintain.
2 This architecture enables each service to be developed by a dedicated development team. Developers can freely choose development technologies and provide API services. This freedom means that developers are not forced to use outdated technology that a project started with, they can choose the technology of today.
3 The microservice architecture pattern is that each microservice is deployed independently. Rapid deployment of changes. The microservice architecture pattern makes continuous deployment possible.
4 The microservice architecture pattern enables each service to scale independently. You can deploy the scale that meets your needs based on the scale of each service. Even more, you can use hardware that is more suitable for serving resource needs.
Shortcomings of Microservice Architecture
1 "Microservice" emphasizes the size of the service, which may lead to a large number of microservices.
2 微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚于，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。但相对于单体式应用中通过语言层级的方法或者进程调用，微服务下这种技术显得更复杂一些。
3 另外一个关于微服务的挑战来自于分区的数据库架构。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。
4 测试一个基于微服务架构的应用也是很复杂的任务。
5 微服务架构模式应用的改变将会波及多个服务。
6 部署一个微服务应用也很复杂，成功部署一个微服务应用需要开发者有足够的控制部署方法，并高度自动化。