它山之石

Tashan stone of

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

它山之石

单体与微服务:哪一个是你最好的选择

来源:派臣科技|时间:2019-07-06|浏览:

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

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

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

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

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

理解的选择

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

Particle公司的首席技术官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构建。

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

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

留言

返回顶部

君
重庆网站建设派臣公司