为什么应该使用微服务(Microservices) ?

如今,微服务非常流行。几乎每个人都喜欢。不仅仅是Netflix、亚马逊或谷歌,似乎几乎每个人都采用了这种架构风格。虽然微服务已经存在了很长一段时间,也有很多关于它的文章,但我今天想再写一篇,所以请耐心听我说。

要理解对微服务的需求,我们需要理解典型的单体三层架构的问题。

整体式架构是什么?

整体式是指把所有的东西都组合在一起。整体应用程序是自包含的应用程序。必须有应用的所有组件,才能使代码工作。

以构建在三个部分中的典型的三层传统web应用程序为例:用户界面、数据库和服务器端应用程序。这个服务器端应用程序称为monolith,它进一步分为3层—表示层、业务层和数据层。整个代码在同一个代码库中维护。为了使代码工作,它被部署为单个整体单元。任何微小的更改都需要构建和部署整个应用程序。

什么是微服务架构?

微服务体系结构是一种体系结构风格,在这种体系结构风格中,整个应用程序被划分成松散耦合的、独立的、围绕业务领域建模的服务。微服务中的“微”是非常具有欺骗性的。人们对此争论不休,但在我看来,它并没有规定服务的大小。再一次,这是另一个我们应该有另一天的讨论。让我们前进。

重点是,每个独立的服务都有一个业务边界,可以独立开发、测试、部署、监视和扩展。它们甚至可以用不同的编程语言开发。

在基于微服务的体系结构中,每个组件或服务都有自己的数据库。没有集中式数据库,就像一个整体的情况一样。您甚至可以根据需要为每个微服务使用NoSQL、RDBMS或任何其他数据库。这使得微服务真正独立。

单体Monolith架构与微服务对比

扩展难易程度

这些应用程序只能通过在负载均衡器后面有多个完整应用程序实例来水平缩放。如果应用程序中的特定服务需要扩展,那么没有简单的选项。您需要完整地扩展应用程序,这是对资源的不必要浪费。

相反,基于微服务的应用程序允许您根据自己的需求独立地扩展单个服务。在上面的图中,如果服务B需要缩放,您可能有10个实例,而其他的保持原样。这可以根据需要随时更改。

部署方便程度

整个代码库被部署,而不仅仅是受影响的代码。对单个应用程序的任何部分/层所做的任何更改都需要构建和部署整个应用程序。单个开发人员还需要下载整个应用程序代码,而不只是下载他/她所影响的用于修复和测试的模块。这也会影响持续部署。

另一方面,在微服务体系结构中,如果只需要在100个微服务中的一个中进行更改,那么只需要构建和部署经过更改的微服务。不需要部署所有内容。事实上,如果需要,微服务甚至可以在一天中部署好几次。

越来越多的应用程序的复杂性

随着单体应用程序(特性、功能等)的增长,团队也会随之增长,很快,应用程序就变得复杂和交织在一起。随着不同的团队不断修改代码,维护模块化结构变得越来越困难,最终导致混乱的代码。这不仅会影响代码质量,还会影响整个组织。

在基于微服务的应用程序中,每个团队都在各自独立的微服务上工作,这使得制作交织在一起的代码变得不那么困难。

没有明确的所有权

在单体应用程序中,看起来独立的团队实际上并不独立。它们同时在同一个代码基上工作,但彼此之间严重依赖。

在基于微服务的应用程序中,独立的团队在独立的微服务上工作。一个团队将拥有一个完整的微服务。工作有明确的所有权,对服务的所有内容都有明确的控制,包括开发、部署和监视。

故障级联

如果不正确地设计,单个应用程序的某个部分的故障可能会级联并导致整个系统崩溃。

在基于微服务的架构中,我们可以使用断路器来避免这种故障。

开发和运维隔离

开发团队通常会进行开发、测试,一旦部署,就会将维护和支持的所有权交给运营团队。开发团队解散了,运维团队接管了所有权,并努力在生产中支持单块应用程序。

在基于微服务的应用程序中,团队是在“构建它,运行它”的理解下组织起来的。开发团队继续拥有产品中的应用程序。

在技术/语言

用一个整体,一个人被锁定在实现的技术/语言。如果需要进行技术/语言更改,则必须重写整个应用程序。

使用微服务,每个服务都可以根据需求和业务以不同的技术或语言实现。任何更改服务的技术/语言的决定只需要重写该特定服务,因为所有微服务彼此独立。

提供正确的工具/技术来支持微服务

几年前,还没有合适的工具和技术来支持微服务。自从Docker容器和云基础设施(尤其是PaaS)向大众开放以来,由于微服务无需经过传统的供应程序就能提供自由,因此被大量采用。

结论

我们已经详细讨论了单片架构和微服务架构风格。我们还讨论了单体应用程序的各种关键问题,以及微服务如何解决这些问题。简而言之,选择微服务体系结构有以下好处:

独立开发和部署服务

速度和敏捷性

更好的代码质量

围绕业务功能创建/组织代码

提高了生产率

容易扩展

在某种程度上,选择实现技术/语言的自由

即使有微服务体系结构提供的所有好处,它也不是一颗银弹。它有自己的复杂性。考虑一个大项目中数百个服务的多个实例。你将如何监控这些?在任何服务失败的情况下,如何跟踪、跟踪和调试错误?

所有这些开销都是高效应用程序需要解决的问题。

原文发布于微信公众号 - 程序你好(codinghello)

原文发表时间:2018-08-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java架构师学习

浅析常用软件架构的三种架构模型

常用的软件架构模型可以归类为三种架构模型:3/N层架构、“框架+插件”架构、地域分布式架构。 一.三种架构模型 1.3/N层架构 这是经典的多层架构模型,对于稍...

4677
来自专栏携程技术中心

干货 | 携程网络防火墙自动化运维之道

? 随着互联网技术的不断发展,在线网站的规模越来越大,防火墙作为网站的安全屏障,被大量的使用。防火墙数量的增加以及防火墙中安全策略条目的增加,安全工程师的运维...

37310
来自专栏CSDN技术头条

如何创建一条可靠的实时数据流

数据的生命周期一般包含“生成、传输、消费”三个阶段。在有些场景下,我们需要将数据的变化快速地反馈到在线服务中,因此出现了实时数据流的概念。如何衡量数据流是否“可...

2428
来自专栏java思维导图

为什么一定要前后端分离?

由于近期前端抽不出资源,博主最近接手一个前端项目的代码维护工作。拿到手一看,一脸懵逼,和博主当年所学的jsp开发方式、利用ajax来请求数据的单页面开发方式完全...

1564
来自专栏FreeBuf

HTTP/2性能更好,但是安全性又如何呢?

根据W3Techs的调查数据显示,目前大约有11%的网站使用了新型的互联网通信协议–HTTP/2,而在一年之前,其占比只有2.3%。 没错,这个新的协议的确可以...

21710
来自专栏杨建荣的学习笔记

MySQL性能扩展的架构优化方案(一)

这几天有一个业务库的负载比往常高了很多,最直观的印象就是原来的负载最高是100%,现在不是翻了几倍或者指数级增长,而是突然翻了100倍,导致业务后端的数...

943
来自专栏EAWorld

微服务框架落地实践之路

在微服务的浪潮下,如何根据企业自身的业务特点,合理的运用开源技术落地微服务架构成为关键。本文作者认为,在实施微服务架构的过程中,结合企业自身业务特点落地的微服务...

3728
来自专栏京东技术

京东物流性能测试理论梳理 ——性能测试的正确打开方式

京东全球年中购物节火热进行中,2018年6月1日0点到6月18日24点累计下单金额达1592亿元,出库订单金额同比增长超过37%!618期间,90%以上自营订单...

1772
来自专栏性能与架构

内容平台 Medium 的技术体系

Medium 是全球知名的内容平台,访问量惊人 据半年前的数据统计,用户在 Medium 上阅读时间的总和已经达到 2600年,每月有2500万阅读者,每周有数...

3696
来自专栏DevOps时代的专栏

移动端持续集成的落地

我今天给大家分享的主题主要是移动端持续集成的移动端落地。先给大家介绍一下我的一些背景,大概做了十年左右的软件的质量研发,还有DevOps 的一些工作。然后经历了...

1351

扫码关注云+社区

领取腾讯云代金券