单体架构与微服务架构（英文）
文章目录
- Monolith vs Microservices
- What is a Monolith i.e. a monolithic architecture?
- Example:
- Benefits:
- Drawbacks:
- What is a microservice i.e. a microservice architecture?
- Example:
- Benefits:
- Drawbacks:
- Summary
Monolith vs Microservices
原文
Over the years I read a lot of articles and stories about the differences between Microservices Architectures and Monolithic Architecture (Monoliths). Today I am about to tell you my own version.
What is a Monolith i.e. a monolithic architecture?
A monolithic application, let’s call it a Monolith, is an application delivered via a single deployment unit. Examples could be an application delivered as single WAR or a Node application with a single entrypoint.
Example:
Let’s make an example: A classic online shop. Our business boundaries are ORDERS, ITEMS, CUSTOMERS, SHIPPING and PAYMENT. Provided ways of interacting with the service are: A REST api and a web-frontend.
Building a Monolith, all these things would be managed within the same artifact. I didn’t write “same process”, since this wouldn’t be true for scenarios where multiple instances of our artifact would be running to deal with higher loads.
See an example in the following figure, where all parts are within the same deployment unit:
Benefits:
A big benefit of a Monolith is that it is easier to implement. In a Monolith you can quickly start to implement your business logic before spending your thoughts about interprocess communication.
Another thing are End-to-End (E2E) Tests. In a monolithic architecture these tests are easier to execute since the monolith brings everything.
Regarding operations: The Monolith is easy to deploy and easy to scale out. For deploying you could get away with a script uploading your artifact and just starting the application. Scaling out is achieved by putting a Loadbalancer in front of multiple instances of your application. As you can see a Monolith is pretty easy to operate.
After reading all these cool things about microservices, let’s have a look at the not so sunny side …
Drawbacks:
Monoliths tend to degenerate from their clean state to a so called “big ball of mud”. Shortly written this is a state were architectural rules were violated and over time the components grew together.
This degeneration slows down the development process - every future feature will be harder to develop. Due to the components grewing together, they also need to get changed together. Creating a new feature could mean to touch 5 different places, 5 places you have to write tests, 5 places which could have unwanted side-effects on existing features.
Earlier I said that scaling is easy within a Monolith. It really is - until it isn’t. Scaling out can be problematic when only a single part of the system needs the additional resources. Within a monolithic architecture you can’t scale single parts of your system.
There is barely any isolation. An issue or bug in a module can slow or bring down the whole application.
Building a Monolith often comes with choosing a framework. Switching away or updating away from your initial choice can be hard since it needs to be done at once and for all parts of your system.
What is a microservice i.e. a microservice architecture?
In a Microservice architecture loosely coupled services interact with each other to fulfill the tasks belonging to their business capabilities.
Microservices pretty much got their name from the fact that the services are smaller than in a monolithical environment. Still the micro is more about cutting business capabilities and not just about the size.
In comparison to a Monolith, with Microservices you have multiple deployment units. Each service gets deployed on its own.
Example:
Let’s have a look at our previous example: The Online Shop.
Like before, we got the boundaries: ORDERS, ITEMS, CUSTOMERS, SHIPPING and PAYMENT.
The difference now is that these all have their own service and database. They are loosely coupled and might interact with different protocols (e.g. REST, gRPC, messaging) across their boundaries.
The following figure shows the same example as before but decomposited as microservices. I left out the communication between each service since this could definitly clutter the chart, but I hope that you still get the idea:
But what are the benefits and cons of this variant?
Benefits:
It is easier to keep them modularized. It is technically enforced by the hard boundaries between the single services.
In big companies different services can be owned by different teams. There services can be re-used across the whole company. It also allows teams to work on their services mainly independently. No need to coordinate deployments between teams. Developing scales better with increasing number of teams.
Microservices are smaller and have smaller scopes. Due to this they are in general easier to understand and to test.
Smaller sizes also helps when it comes to compilation times, startup times and time it takes to execute the tests. All of these factors benefit developer productivity since it means less time spent waiting in each phase of the development.
The shorter startup times and the possibility to deploy Microservices independently from each other really pay into CI/CD. It is much smoother in comparison to regularly deploy a monolith.
Each Microservices is not bound to the technology used in other services. Everywhere we can use the best fitting technology. Older services can be quickly rewritten to use newer technologies.
Better fault isolation in comparison to the monolithic approach. A well designed distributed system will survive the crash of a single service.
Drawbacks:
Everything sounds too good to be true, but there are also some drawbacks to consider:
Having a distributed system brings its own complexity:
In a distributed system you have to deal with Partial failure, a more difficult Testing Interaction (E2E Tests) and also often a higher difficulty in implementing interaction between services.
Another thing to consider is that transactions are easier to handle in a monolith. A solution to this issue is the Saga Pattern which is a good solution but still more cumbersome to implement in practice.
Let’s have a look at the operational side of things:
There is an operational overhead, a bunch of microservices are more difficult to operate than a few instances of a signle monolith.
Besides the difficulty, microservices can also require more hardware than traditional monoliths. Sometimes microservices can outperform a single monolith if there are parts of it which require scaling it out to the extreme.
Changes affecting multiple services need to get coordinated between multiple teams, this can be especially hard if the teams not yet had any contact before.
Summary
There are no silver bullets! Everything is trade-off.
First of all it depends on your organizational structure. You have 6 teams which will be working on a single product? Microservices might be a good fit.
You have a team of 3 developers? Probably they will be fine building and maintaining a monolith (see: Wikipedia: Conway’s Law)
The other factors are rate of change and complexity. A high rate of change and a high complexity would both be factors which move my decision more to the Microservice architecture.
In contrast, when you are not really familiar with the domain, starting out with a Monolith can be really beneficial. Just do yourself a favor and try your best on keeping it modularized. This will easen the way in case you ever decide to cut your Monolith into multiple services down the road.
In case you are more interested in a post about experience with microservices - feel free to go to my article: What two years with Microservices taught me
原文
引用
单体架构与微服务架构（英文）相关推荐
- java调用webservice_笃学私教：Java开发网站架构演变过程-从单体应用到微服务架构详解...
原标题:笃学私教:Java开发网站架构演变过程-从单体应用到微服务架构详解 Java开发网站架构演变过程,到目前为止,大致分为5个阶段,分别为单体架构.集群架构.分布式架构.SOA架构和微服务架构.下 ...
- 漫谈单体架构与微服务架构（上）：单体架构
最近微服务架构特别火爆,就跟人工智能.区块链一样,软件架构设计如果不提微服务,感觉就像是与世界先进的架构风格和开发技术脱了节似的,各方各面都无法彰显高大上的气质. 本来再打算使用一套系列文章来讨论微服 ...
- 单体应用架构和微服务架构的区别
一.单体应用架构概念 一个归档包(可以是JAR.WAR.EAR或其它归档格式)包含所有功能的应用程序,通常称为单体应用. 而架构单体应用的方法论,就是单体应用架构. 二.单体架构示意图 三 ...
- 分布式与微服务——Iaas，Paas和Saas、单体应用和缺点、微服务概念、传统 分布式 SOA 架构与微服务架构的区别、微服务实战、什么是RPC、CAP定理和BASE理论、唯一ID生成、实现分布式
文章目录 1-什么是Iaas,Paas和Saas 一 IaaS基础设施服务 二 paas平台即服务 三saas软件即服务 四 总结 2-单体应用和缺点 一 单体应用 二 单体应用的缺陷 3-微服务概念 ...
- 系统架构的演变过程（单体应用架构、垂直应用架构、分布式SOA架构、微服务架构）
文章目录 系统架构演变 单体应用架构 垂直应用架构 分布式SOA架构 什么是SOA 微服务架构 分布式SOA架构和微服务架构对比 系统架构演变 随着互联网的发展,网站应用的规模不断扩大,常规的应用架构 ...
- 从单体结构到微服务架构的转变，微服务入门
单体架构 VS 微服务架构 1.1从单体架构说起 一个工程对应一个归档包(war),这个war包 包含了该工程的所有功 能.我们成为这种应用为单体应用,也就是我们常说的单体架构(一个 war包打天下) ...
- 单体应用、SOA架构、微服务架构的对比
目录 前言: 单体架构 SOA架构 微服务架构 前言: 随着近年来云技术的发展,越来越多的用户选择使用云技术来代替传统的IT基础设施.在云技术发展的早期,业界的关注点集中在虚拟化.分布式.存储等laa ...
- 单体架构--＞SOA架构--＞微服务架构
上诉架构图采用了分层架构,按照调用顺序,从上到下为表示层.业务层.数据访问(DAO)层.DB层.表示层负责用户体验,业务层负责业务逻辑,包括电影.订单和用户三个模块.数据访问层负责DB层的数据存取,实 ...
- 从单体架构到微服务架构的拆分
目录 一.概述 二.微服务拆分 三.微服务项目架构图 一.概述 单体架构.分布式架构和微服务架构是三种不同的软件架构模式,它们各有特点和适用场景. 单体架构(Monolithic Architectu ...
- nodejs微服务：单体架构与微服务架构
单体架构 单体架构在中小企业内部用的是非常多的,就是完整独立的web服务 当业务不复杂,团队规模不大的时候,单体架构比微服务架构具有更高的生产率 1 ) 单体架构的程序部署在单台服务器 这种架构是目前 ...
最新文章
- 你觉得 ThreadLocalRandom 这玩意真的安全吗？
- python把数据写入excel_Python读取和写入Excel文件（转）
- 【ARM】MRS MSR指令
- 使用递归计算1-n之间的和
- weblogic各个版本对JDK和Spring的支持度
- HashTable数据类型的增删改查操作0404
- Discuz 7.2 /faq.php SQL注入漏洞
- 端口号及对应的服务汇总 （适用于Linux/Windows系统）
- 以太坊 链私有链环境搭建（windows）
- C专家编程第二章，c语言特性的不足
- OpenCV threshold函数详解
- 搜狗站长工具：索引量与收录量的解释，它等同于site的收录吗？
- 【稳定性day14】支付宝技术风险体系TRaaS——把风险去服务化、产品化
- KSO-c#中 event事件的简单使用
- Greenplum-Spark Connector 介绍
- xampp mysql远程连接_XAMPP mysql远程连接
- 文档生成工具-Doxygen使用方法以及注释规则
- 踩坑篇，多达21页的，超级详细的Oracle安装和配置教程，没有之一
- GMOS6803为7频段高精度RTK系统应用桥梁监测
- 肩部三角肌介绍：肌肉英文名称和图示