为什么你总是选择微服务?(一体化架构有疑问)

有没有想过为什么像苹果,eBay和Netflix这样的公司非常关心微服务?是什么让这个简单的架构变得如此特别以至于它被过度炒作?将整个正在运行的应用程序从一体化转移到微服务架构是否值得付出的努力和痛苦?当我们开始在项目中使用微服务时出现了很多类似的问题。在本博客中,我们将尝试回答这些问题并深入研究微服务架构,并将其与一体化架构进行比较。

什么是微服务?它与一体化有何不同?

微服务是小型自主服务工作的集合。让我们再简化一下这个定义。

微服务 - 也被称为微服务体系结构 - 是一种架构风格,它将应用程序构建为一系列松散且互联的实现各自业务功能的服务。微服务架构支持大型复杂应用的持续交付/部署。

随着我们编写代码以便于添加新功能,代码库不断增加。随着时间的推移,因为代码库非常大,我们可能很难知道哪些地方需要修改。

一体化系统中,我们努力确保代码属于一体化系统以便于与解决这些问题,我们通常采用创建抽象对象或模块的方法来确保我们的代码更内聚以便于应对这些问题。微服务采用独立服务的方法。我们将服务边界集中在业务边界上,明确了代码在什么地方具有什么功能。

为什么不采用一体化架构?

有个主要问题是,如果我们有一个功能完整的一体化应用程序正在运行,为什么要转换?为什么要增加开销并付出额外的努力?此外,转换是否值得付出的努力和得到的痛苦?

我们需要理解的第一件事是一体化应用程序并不是一无是处的。变化和进化是生活的一部分。虽然一体化应用程序的确解决了许多经典架构问题,例如如部署(因为它是作为一个单元部署)和测试很容易,但与优点相比,它有很多缺点。我们在使用一体化应用程序时遇到的主要问题包括:

  • 可扩展性 - 扩展应用程序有可能很困难 - 一体化架构只能在一个维度上进行扩展。一方面,它可以通过运行更多的应用程序副本来扩大交易量。使用一体化架构,我们无法独立扩展每个组件,因此即使大多数组件可能不需要扩展,整个应用程序也需要进行扩展。
  • 可靠性 - 一体化应用的另一个问题是可靠性。任何模块中的一个错误(例如内存泄漏)都可能导致整个过程失败。而且由于应用程序的所有实例都是相同的,因此该错误将影响整个应用程序的可用性。
  • 可用性 - 即使一个服务失败,整个应用程序也必须关闭。由于所有服务都是作为一个单元部署的,因此每次服务失败或出现错误时,都会牵累整个应用程序。
  • 敏捷性 - 在一体化应用程序中,即使应用程序中的小型组件需要更改,整个应用程序也需要重新打包并组装在一起。因为重建整个应用程序需要相当长的时间,我们可以很确定这降低了应用程序的敏捷性。
  • 持续部署 -如果您持续部署,那么它在这方面会表现会很差,因为即使应用程序发生小的变化,构建时间也会大大增加,并且会明显减少部署频率。而且即使是微笑的更改,您也必须在每次更新时重新部署整个应用程序。
  • 独立软件栈 -一体化应用程序很难适应不同的软件栈。由于框架或语言的变化会影响整个应用程序,因此付出的时间和成本很大。

除了这些问题之外,程序员在处理一体化应用程序时还面临着许多其他问题。因此考虑到这些问题,似乎需要一个不同的架构至少可以解决其中一些问题。这就是微服务。

微服务 - 救世主?

现在我们已经遇到了在使用一体化应用程序时可能会遇到的一些问题。那么微服务能解决这些问题吗?他们是否做的更好或者只是另一个被炒作的架构?

正如我们已经看到的,微服务的主要思想是将您的应用程序分解为一组较小的互连服务,而不是构建一个单一的一体化应用程序。每个微服务都是一个小型应用程序,它有自己由业务逻辑组成的体系结构。

现在我们对微服务有了一个大概的概念,让我们来看看微服务提供给我们哪些一体化结构没有的优点:

  • 可扩展性:每个微服务可以独立扩展而不会影响其他微服务,因此它明显优于一体化应用程序,因为它们都被整合到同一个部署单元中,所以一体化应用程序大量的资源被浪费在扩展不需要的服务上。
  • 可靠性:微服务的故障仅影响自身及其使用者,而在一体化模型中,一个服务故障可能会导致整个一体化服务失败。即使一个微服务失败,其他微服务也可用,并且可以很快修正错误的微服务。
  • 可用性:推出新版本的微服务只需要很少的停机时间,而在一体化服务中推出新版本的服务需要整个服务重启并且速度较慢。一个失败的微服务可以在很短的停机时间内迅速被纠正。
  • 敏捷性:特定微服务的变化可以非常迅速地完成,并且可以非常迅速地进行部署,这使其成为非常适合不断变化业务需求的体系结构,这里意味着非常敏捷的环境。
  • 持续部署:微服务体系结构可以使每个微服务独立部署,因此它可以为复杂应用程序进行持续部署。此外,与一体化应用程序不同,微服务中的代码可以非常迅速地完成更改来跟踪业务需求的变化,从而缩短开发周期。
  • 独立软件栈:对于微服务,每个服务都是独立的,每个服务都是一个新项目; 每项服务都可以用符合要求的任何语言进行开发。因此,不同的软件栈可以用于不同的微服务。

除此之外,微服务还为我们提供了更多优势:

  • 管理:应用程序开发工作可以分为小型和独立的团队。
  • 数据分散:没有集中的数据库。每个模块都有自己的数据库,所以数据是分散的。您可以使用NoSQL或关系数据库,这取决于模块。
  • 更好的可理解性:分布式服务使新开发人员更容易理解服务的功能。此外,由于特定模块专用于特定服务,因此它有助于开发人员更好地了解该服务,而不是尝试弄清楚整个应用程序。

类似的例子不胜枚举...

但等等,没有人是完美的,对吧?微服务也不例外

仅仅因为这个行业很火并不意味着它没有缺点。相信与否,微服务并不完美。他们确实存在不同类型的缺点。我们来看看其中的一些:

  • 运营复杂性:您需要一个成熟的运营团队来管理大量需要定期重新部署的服务。
  • 测试:测试微服务应用程序也比一体化的Web应用程序更复杂。对于服务进行类似的测试,您需要启动该服务以及它所依赖的任何服务。
  • 部署:在分布式系统的情况下,部署微服务变得更加复杂,因为有许多工作,脚本,传输区域和配置文件需要部署。
  • 多个数据库和事务管理:微服务具有分布数据库体系结构。在微服务的应用程序中更新多个业务实体的事务需要更新不同服务拥有的多个数据库。
  • 通信:在微服务中,每种服务都通过API /远程调用进行通信,这比一体化软件的进程间通信调用花费更多。
  • 分布式系统的复杂性:作为一个分布式系统,微服务具有一定程度的复杂性以及需要处理的几个问题,如网络延迟,容错率,消息序列化,不可靠的网络,异步性,版本控制,应用程序层内的各种负载等等。

现在我们对一体化和微服务是什么以及他们的优缺点有一个大概的认识。

总而言之,一体化架构更适合简单轻量级的应用。微服务架构模式适用于复杂的,不断变化的应用程序,尽管在缺点和实施方面的具有一定的挑战。

在开始使用任何一种架构之前,需要明智地做出选择,并考虑您从一体化转换或迁移到微服务所付出的努力是否值得随之而来的痛苦和复杂性。

在下一篇博客中,我们希望讨论在转向微服务架构时一些好的实践经验。请持续关注。

希望这篇文章可以有所帮助。祝您编程愉快!

本文的版权归 eru 所有,如需转载请联系作者。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏微服务

关于大型网站技术演进的思考(一)--存储的瓶颈(1)

前不久公司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训,两天12个小时信息量非常大,知识的广度和难度也非常大,培训完后我很难完整理出全部听到的知识...

36915
来自专栏云计算D1net

确保混合云备份与灾难恢复的数据一致性

为了使备份和灾难恢复成功工作,数据必须同步。这些技巧有助于IT团队确保数据一致性。 ? 理想的世界中,如果混合云平台的一部分出现问题,处理只会减慢,然后自动恢复...

2639
来自专栏大数据和云计算技术

超融合方案分析系列(4)H3C超融合方案分析

前言 话说天下大势,分久必合,合久必分!超融合到了爆发的边缘! 作者是国内研究超融合相当早的专家,有非常强的理论基础和实战经验。上几篇分析文章,对nutani...

4716
来自专栏大数据

云数据-欲练神功必先写文档

当构建DR计划时,第一步是查看用来交付IT服务的应用,并且决定灾难发生时需要保护什么。这意味着创建需要运行的应用和服务的清单。很多企业已经转向虚拟化作为其核心服...

1858
来自专栏架构师小秘圈

存储的瓶颈--大型网站技术演进思考

作者:夏天的森林 出处:cnblogs.com/sharpxiajun/p/4237704.html 一,题记 前不久公司请来了位互联网界的技术大牛跟我们做了一...

3618
来自专栏大数据文摘

【干货】大数据平台建设实践与探讨

2446
来自专栏腾讯移动品质中心TMQ的专栏

【UTP自动化测试平台系列之一】架构介绍与优化

导语 UTP自动化测试平台是TMQ的一个联合项目,目的是方便各项目测试人员更好地开展自动化测试建设工作,减少重复平台建设的成本,提高产品的自动化测试效率。 该...

2746
来自专栏架构师之路

好架构是进化来的,不是设计来的(58架构演进)

好的架构化是进化而来的,不是设计出来的 ----58沈剑 核心内容:58同城流量从小到大过程中,架构是如何演进的?遇到了哪些问题?以...

38414
来自专栏CSDN技术头条

专访当当网张亮:深度解读分布式作业调度框架elastic-job

【编者按】互联网从诞生到现在,网站的规模不断扩大,存储和处理的数据量也远远超出了人们的想象,又随着对信息实时性、多媒体需求大幅增长的现象,互联网架构面临越来越大...

1936
来自专栏我的技术专栏

微服务的一些概念

传统的单体架构,把所有的功能都集中在一起,打包为一个war包,或者是可执行程序。部署的时候,需要部署一个完整的应用,升级时,也需要替换整个war包或是可执行程序...

1337

扫码关注云+社区