架构之:微服务和单体服务之争
文章目录
- 简介
- 先单体再微服务
- 直接从微服务开始
- 总结
简介
微服务和单体服务的各自好处之前的文章中已经讲的很明白了。本篇文章不是探讨到底应该用哪种服务架构。而是假设项目最终会采用微服务架构，那么就会有两种情况，第一种情况下项目一开始的时候，是先使用单体服务然后在项目发展过程中逐渐转换成微服务，另外一种就是一开始就采用微服务的架构。
本文将会讨论一下采用这两种方式的原因。
先单体再微服务
微服务是一种有用的架构，但即使是他们的拥护者也表示，使用微服务只对更复杂的系统有用。
因为使用微服务本身是有一个管理上的服务成本，这个成本会减慢团队的开发速度。所以对于更简单的应用程序来说，使用单体服务更加简单。所以该方式的支持者认为应该在最初将新应用程序构建为单体应用，即使最后很有可能转换为微服务。
第一个原因是在系统的初期，我们并不知道它到底会有多少用户，并且在软件的第一个阶段，我们通常考虑的是软件开发的速度，所以大家可能更加倾向于使用单体应用。如果使用了微服务，如果该微服务的设计比较糟糕，那么会导致后续系统无法扩展，只能重新设计。
第二个原因是，只有在服务之间提出良好、稳定的边界时，它们才能很好地工作，服务之间的任何功能重构都比单体应用困难得多。但即使是在熟悉领域工作的经验丰富的架构师，在一开始就很难确定边界。通过首先构建一个单体服务，您可以弄清楚正确的边界是什么，从而在边界之上再进行微服务的转换。
一种将单体服务转换为微服务的做法是，将单体服务经过合理的设计，比如注意软件内部的模块化，包括 API 边界和数据存储方式。如果能够做好这一点，那么后续转向微服务是一件相对简单的事情。
另一种方法是从单体应用开始，逐渐剥离边缘的微服务。这种方法可以在微服务架构的核心留下一个庞大的单体，但大多数新的开发使用微服务，而单体应用不再进行扩展。
还有一种是完全替代单体应用。这样可以完全抛弃单体带来的架构负担，重新开始。代价就是需要多花人力和时间。
所以，如果你不能构建一个结构良好的单体应用，那么是什么让你认为你可以构建一组结构良好的微服务？
直接从微服务开始
当然，也有人持有不同的意见，因为他们认为：
如果你确实能够构建结构良好的单体应用，那么您可能一开始就不需要微服务。
也就是说，不管是单体服务还是微服务，在构建之前都需要进行详细的需求分析，经过了透彻的分析，那么是否需要使用微服务一键很了解了，各个服务的边界也被界定出来了，那么为什么不直接使用微服务呢？
微服务的主要好处就是在不同的服务之间建立了一个边界。这样我们很难弄错一些事情，比如连接不应该连接的部分，并耦合那些不应该被耦合的部分。
在理论上，如果你的程序遵循了特定的规则，并在整体应用程序中建立明确的界限，那么您不需要微服务，但是在实际的工作中，这个界限总是会被跨域。
你可能会假设有许多可以被很好地分离的微服务隐藏在你的单个项目中，等待被提取。但实际上，很难进行这样的划分。
如果你从一个整体开始，各个部分将变得非常紧密地相互耦合。这就是单体应用的定义。这些部件将依赖于它们都使用的平台的特性。它们将基于共享的抽象进行通信，因为它们都使用相同的库。他们将使用仅当它们托管在同一进程中时才可用的方式进行通信。更糟糕的是，这些部分将（几乎）自由地共享域对象，依赖相同的共享持久性模型，假设数据库事务随时可用，因此无需补偿……从而使得再次分割事务变得非常困难。所以将现有的单体拆分成单独的部分非常困难。
所以当你开始时，就应该考虑你构建的子系统，并尽可能独立地构建它们。当然，只有在您认为您的系统大到足以保证这一点时才应该这样做。如果只有您和您的一位同事在几周内构建了一些东西，那么您完全不需要使用微服务。
总结
软件架构的世界总是很有趣，我们在探索的过程中也会学到很多不一样的视角。
本文已收录于 http://www.flydean.com/10-microservices-monolith/
最通俗的解读，最深刻的干货，最简洁的教程，众多你不知道的小技巧等你来发现！
架构之:微服务和单体服务之争相关推荐
- 架构之:微服务架构漫谈
文章目录 简介 微服务和单体服务 微服务的特征 组件服务化 组织的划分 服务之间的通信 去中心化治理 去中心化数据管理 自动化部署 对异常的响应 总结 简介 微服务的架构出现已经很久很久了,微服务架构 ...
- 单体服务与分布式服务
单体服务与分布式服务 分布式架构 分布式架构(集群) 单体服务与分布式服务区别 什么时候使用分布式/集群? 单机无法支持的时候. 想要更好的隔离性(功能与功能). 想要更好用户体验的时候. 想要更好的 ...
- 系统由单体架构到微服务架构到底是如何演进的？
随着互联网的发展,互联网企业的业务也在不断的飞速发展,进而导致系统的架构也在不断的发生着变化.总体来说,系统的架构大致经历了:单体应用架构->垂直应用架构->分布式架构->SOA架构 ...
- 一文了解四种软件架构：Serverless架构、微服务架构、分布式架构、单体架构
如果一个软件开发人员,不了解软件架构的演进,会制约技术的选型和开发人员的生存.晋升空间.这里我列举了目前主要的四种软件架构以及他们的优缺点,希望能够帮助软件开发人员拓展知识面. 一.单体架构 单体架构 ...
- 8 场 5 胜，微服务 VS 单体架构
来源:thenewstack.io/ microservices-vs-monoliths-an-operational-comparison/ 对比1:网络延迟 对比2:复杂性 对比3:可靠性 对比 ...
- 为什么Segment会从微服务退回单体架构？
近年来,我们发布了很多文章介绍企业向微服务迁移的成败经验.最近,Segment的Alexandra Noonan写了一篇文章,讲述了他们从单体架构迁移到微服务,之后又退回单体应用的经历.文中Alexa ...
- 华为架构师8年经验谈：从单体架构到微服务的服务化演进之路
本次分享的技术大纲如下: 传统应用开发面临的挑战 服务化实践 服务化不是银弹 服务化架构的演进方向 一 .传统应用开发面临的挑战 挑战1-- 研发成本高 主要体现在如下几个方面: 代码重复率高 在实际 ...
- 【转】应用架构一团糟？如何将单体应用改造为微服务
概述 将单体应用改造为微服务实际上是应用现代化的过程,这是开发者们在过去十年来一直在做的事情,所以已经有一些可以复用的经验. 全部重写是绝对不能用的策略,除非你要集中精力从头构建一个基于微服务的应用. ...
- 漫谈单体架构与微服务架构（上）：单体架构
最近微服务架构特别火爆,就跟人工智能.区块链一样,软件架构设计如果不提微服务,感觉就像是与世界先进的架构风格和开发技术脱了节似的,各方各面都无法彰显高大上的气质. 本来再打算使用一套系列文章来讨论微服 ...
最新文章
- Nginx-08：Nginx配置高可用
- V2EX › 郁闷于Python GUI开发，有没有好的框架啊？
- linux系统串口设置参数,linux 串口编程记录（一）串口参数设置(示例代码)
- [9月29日的脚本] 枚举SharePoint列表（PowerShell）
- CocosCreator1.x实现水流动的效果
- rust盖错了怎么拆除_细说Rust错误处理
- 数据结构之线性表-链式存储之单链表(一)
- Python邮件操作实例：发个邮件用Python实现远程自动关机
- Docker版本Omnibus Gitlab 加Lets Encrypt免费SSL一键搭建
- 数值计算（一）：引论
- android iphone 开发者选项,手机开发者选项中的妙用，让你的安卓系统流畅如iOS
- 学习笔记61—兴趣阅读之经济学
- emby ios 收费_点播、直播一条龙，使用Jellyfin打造最强媒体中心（篇一）
- CentOS7的磁盘分区操作
- Flink入门教程(三)——窗口(一)
- 静态html页面如何兼容pc和移动端
- 高德地图天气图标符号大全_手机版腾讯地图和高德地图实测对比
- CAN通信中终端电阻的作用
- 区划代码和城乡划分代码
- 3.每天一个java小程序之累加累乘