免费获取策划方案多一份参考,总有益处

重庆网站制作

Web site production

案例602

重庆网站制作

巨石与微服务:你的最佳选择是什么?

来源:派臣科技|时间:2020-02-14|浏览:

首先,让我们定义一下什么是“整体”和“微服务”。一个独立的体系结构是作为一个大型系统构建的,通常是一个代码库。无论更改了什么,通常都会同时部署前端和末端代码。然而,微服务架构是将应用程序构建为一组小型服务,每个服务都有自己的代码库。这些服务是围绕特定功能构建的,通常可以独立部署。

传统的智慧从一块巨石开始说教。当一个精简的团队在紧迫的期限内开始工作时,这种诱惑尤其强烈。但传统智慧总是正确的吗?我的好朋友Darby Frey在担任Gamut的高级平台工程主管后,最近启动了一个新项目。尽管在他之前的公司里,他是用一块巨石开始的,但他发现(在适当的情况下)用一块巨石开始并不总是最好的方法。

在Belly, Darby和他的团队将他们的整体分解成一个相当大的微服务架构。他们设法把它弄到一个好地方,但只是在几个月的试验和磨难后才迁移到微服务。有了这段新鲜的经历,他在Gamut的新项目中对微服务更加谨慎:

“我是‘铁板一块’团队的坚定成员。(我想)让我们建立一个单一的应用程序,然后把事情分开,如果我们开始感到痛苦,”他说。虽然这是一个新项目,但达比的团队规模较小,而且他有严格的时间表,所以从表面上看,一块巨石似乎是显而易见的选择。“(但有了这个新项目),我急于避免重复过去的错误。”

有了这些,他发现自己面临着一个我们都在挣扎的决定,我们应该从一个整体还是一个微服务开始,我们如何决定?

理解的选择

要在两者之间做出选择,我们应该首先确定“整体”和“微服务”的确切含义。

Particle公司的CTO Zachary Crockett告诉我:“系统架构位于一个频谱上……当讨论微服务时,人们往往关注这个频谱的一端:许多微小的应用程序相互传递太多的消息。在这个范围的另一端,你有一个巨大的庞然大物在做太多的事情。对于任何实际的系统,在这两个极端之间都有许多可能的面向服务的体系结构。

定义庞然大物

单片应用程序构建为单个的、统一的单元。通常,一个整体由三部分组成:数据库、客户端用户界面(由HTML页面和/或在浏览器中运行的JavaScript组成)和服务器端应用程序。服务器端应用程序将处理HTTP请求,执行特定于域的逻辑,从数据库检索和更新数据,并填充要发送到浏览器的HTML视图。

在一个整体中,服务器端应用程序逻辑、前端客户端逻辑、后台作业等都定义在同一个庞大的代码库中。结果是:如果开发人员希望进行任何更改或更新,他们需要一次性构建和部署整个堆栈。

与你所想的相反,巨石并不是一个过时的建筑,我们不需要把它留在过去。在某些情况下,一块巨石是最理想的。工程主管史蒂文•Czerwinski Scaylr和谷歌前员工解释说,因为他的团队在Scaylr很小,一个统一的应用程序相比,更易于管理的一切分裂成microservices:“(在早期的Scaylr)尽管我们有这些积极的经验使用microservices在谷歌,我们去(一块)的路线,因为拥有一个庞大的服务器意味着更少的工作对我们两个工程师。”

当考虑一个整体架构时,你的团队应该考虑以下几点:

庞然大物优点

较少的横切关注点:单片架构的主要优点是,大多数应用程序通常都有大量的横切关注点,比如日志记录、速率限制和安全特性,比如审计跟踪和DOS保护。当所有东西都在同一个应用程序中运行时,很容易将组件连接到那些横切关注点上。

更少的操作开销:拥有一个[大型]应用程序意味着只需要为一个应用程序设置日志记录、监视和测试。它的部署通常也不那么复杂。

性能:也有性能优势,因为共享内存访问比进程间通信(IPC)更快。

庞然大物缺点

紧密耦合:随着应用程序的发展,单片应用程序服务往往会变得紧密耦合和纠缠不清,这使得出于诸如独立扩展或代码可维护性等目的而隔离服务变得非常困难。

更难理解:单片架构也更难理解,因为当您查看特定的服务或控制器时,可能存在依赖性、副作用和不可思议的地方。

定义MICROSERVICES

微服务本身并没有本质上的“微”。虽然它们往往比一般的巨石要小,但它们并不一定要小。有些是,但是规模是相对的,而且在组织之间没有衡量单位的标准。

微服务体系结构风格是一种将单个应用程序作为一组小服务来开发的方法,每个小服务都在自己的进程中运行,并与轻量级机制(通常是HTTP资源API)进行通信。这些服务是围绕业务功能构建的,可以通过完全自动化的部署机制独立部署。对这些服务的集中管理很少。

在考虑微服务时,您的团队应该牢记:

Microservices优点

更好的组织:微服务体系结构通常组织得更好,因为每个微服务都有一个非常具体的工作,不关心其他组件的工作。

解耦:解耦的服务也更容易重新组合和配置,以满足不同应用程序的需要(例如,同时服务于web客户端和公共API)。它们还允许在更大的集成系统中快速、独立地交付单个部件。

性能:在适当的情况下,微服务也可以具有性能优势,这取决于它们的组织方式,因为它可以隔离热门服务并独立于应用程序的其余部分进行伸缩。

更少的错误:微服务通过在系统的不同部分之间建立一个难以跨越的边界来支持并行开发。这样做的话,你就很难——或者至少更难——去做错误的事情:也就是说,把不应该连接的部分连接起来,把需要连接的部分连接得太紧。

Microservices缺点

跨每个服务的横切关注点:当您构建一个新的微服务体系结构时,您可能会发现许多在设计时没有预料到的横切关注点。您将需要为每个横切关注点(即测试)产生单独模块的开销,或者将横切关注点封装在所有流量都要经过的另一个服务层中。最终,即使是单片架构也倾向于通过外部服务层来为横切关注点路由流量,但是使用单片架构,可能会延迟工作的成本,直到项目更加成熟。

更高的操作开销:微服务经常部署在它们自己的虚拟机或容器上,导致VM争用工作的激增。这些任务通常通过集装箱船队管理工具实现自动化。

为您的组织做出正确的决定

当您与您的团队坐下来讨论时,优缺点可以为讨论一个架构相对于另一个架构的潜在优点和缺点提供一个通用框架。为了有效地应用这些一般原则,我采访了几十位cto,为您在决定什么对您的组织最有利时创建了一个考虑事项的规则。

你在熟悉的领域吗?

Darby和他在Gamut的团队能够直接研究微服务,因为他有电子商务平台的经验,而他的公司对于客户的需求有着丰富的知识。另一方面,如果他走的是一条未知的道路,那么一块巨石可能是更安全的选择。

你的团队准备好了吗?

你的团队有微服务的经验吗?如果你在明年将团队规模扩大四倍,微服务是否适合这种情况?评估团队的这些方面对于项目的成功至关重要。

如果您的团队准备好了,那么从微服务开始是明智的,因为它允许您从一开始就适应在微服务环境中开发的节奏。

你的基础设施如何?

实际上,您将需要基于云的基础设施来让微服务为您的项目工作。

“(以前),您希望从一个整体开始,因为您希望部署一个数据库服务器。必须为每个微服务设置一个数据库服务器,然后向外扩展,这是一项艰巨的任务。只有一个庞大的、精通技术的组织才能做到这一点。“而今天有了像谷歌云和亚马逊AWS这样的服务,你可以有很多选择来部署微小的东西,而不需要为每个东西拥有持久层。”

评估业务风险

你可能认为微服务是作为一家充满雄心壮志的科技创业公司的“正确”道路。但微服务也带来了商业风险。大卫·施特劳斯解释道:

“许多团队一开始就过度构建了他们的项目;每个人都希望自己的初创公司能成为下一个独角兽,因此,他们应该用微服务或其他一些高度可伸缩的基础设施来构建一切。但这通常是错误的,几乎一直都是。

他接着说,在这些情况下,你认为你需要扩展的领域可能不是首先需要扩展的部分,这导致了错误的努力,即使是需要扩展的系统。

环境很重要

与我交谈的cto具有广泛的单体和微服务经验。一些人满怀信心地从微服务起步,而另一些人则在一开始就固守不变,最终随着初创企业的成长,他们转向了微服务。考虑您自己的上下文和以下场景,以帮助确定哪种体系结构适合您的情况。

什么时候从一块巨石开始

这里有一些场景,表明你应该开始你的下一个项目使用单片架构:

您的团队正处于创建阶段:您的团队很小,只有2-5名成员,因此无法处理更广泛、开销更大的微服务体系结构。

您正在构建一个未经验证的产品或概念证明:您正在构建一个市场上未经验证的产品吗?如果它是一个新想法,它可能会随着时间的推移而改变和进化,因此一个整体是允许快速产品迭代的理想选择。这同样适用于概念证明,你的目标就是尽可能多、尽可能快地学习,即使你最终把它扔掉。

您没有微服务经验:如果您的团队之前没有微服务经验,除非您能够证明在这么早的阶段就冒着“在飞行中”学习的风险是合理的,否则这可能是另一个您应该坚持一个整体开始的迹象。

何时开始使用微服务

以下是一些场景,表明您应该使用微服务启动下一个项目:

您需要快速、独立的服务交付:微服务允许在更大的集成系统中快速、独立地交付单个部件。注意,根据您的团队规模,可能需要一段时间才能看到服务交付的收益,而不是从整体开始。

平台的一部分需要非常高效:如果您的业务正在进行pb级的日志量的密集处理,那么您可能希望用一种非常高效的语言(即c++)构建服务,而您的用户仪表板可能是用Ruby on Rails构建的。

您计划扩展您的团队:从microservices开始,可以使您的团队习惯于从一开始就在独立的小型服务中进行开发,并且通过服务边界将团队分隔开,可以在需要时更容易地扩展您的团队,而无需引入指数级复杂性。

整体并没有消亡,微服务也不是最适合于每一种环境。避免仅仅因为微服务的爆炸式增长就一头扎进它的诱惑。相反,请使用之前的cto的智慧来仔细考虑什么架构对您最有意义。

留言

返回顶部

君
重庆网站建设重庆网站制作巨石与微服务:你的最佳选择是什么?