服务、微服务与无服务器之函数的区别? - Tom Nolle

19-06-29 banq
                   

自单体数据中心以来,软件架构已经走过了漫长的道路,而且这种演变产生的术语比许多组织学习它们的速度更快。随着云计算正在推动软件变革,并成为企业IT计划中几乎普遍的一部分,我们需要了解云软件的结构。这意味着要学习其令人困惑的术语,这个过程因缺乏明确和公认的定义而受到阻碍。

没有哪个比我们引用分布式应用程序的自治组件的方式更明显。我们有“服务”,这个术语已有近十年的历史,但仍在使用中。我们有“微服务”,这肯定不仅仅是微小的服务; 我们有“函数”或“lambdas”,它们通常用于“无服务器”云计算。但有什么区别,我们为什么要关心?

从组件构建软件有三个目标,我们称之为“三个R”:

1. “reuse重用”,意味着可以实现一次常用函数功能并在需要时使用。

2. “redeployment重新部署”,意味着对应用程序的更改可以降低更少的部署中断,

3. “repair修复”意味着由于可用性和性能而更容易修复问题。

从一端到下一端

“服务”,原始的组件化战略,至今仍在使用。按照惯例,服务是执行某些特定业务的应用程序的功能组件。面向服务的应用程序可能具有“添加员工”,“付钱给员工”,“更改员工信息”等服务。业务活动,业务流程和业务事务决定了组件化。

显然,这些都是单个应用程序的组件(在我的示例中属于工资单/人员管理应用),虽然它们总体上比应用程序小,但它们实际上并不是很小,并且它们也不是特别容易重用。您无法轻松地将“付钱给员工”纳入客户资源管理应用程序或检查处理。

这些组件服务通常也以特定方式实施。它们是会持久状态数据的,意味着它们被假定为始终可用,并且是有状态的,这意味着它们在事务之间存储信息。前一种情况意味着它们不被使用时也会浪费云中的资源,因此而必须为这些服务组件始终在线可用而付费,虽然经常不被真正使用!同时,由于在多个事务之间存储信息,这是由状态的,就无法通过创建多个副本来共享负载来扩展性能,因为相同的信息不会存储在原件中的副本中。

“函数功能”是另外一种情况。函数是一个软件组件,其输出完全取决于输入; 没有内部存储或使用。Output = 2xInput1 + Input2 是一个非常简单的函数的示例。函数显然很小并且是通用的,因此您可以轻松地重用它们,并且因为输出只是输入的函数,所以您可以为函数的任何副本提供输入并获得相同的结果。这使它们具有完全可扩展性和弹性。由于无服务器计算仅在使用时才加载,因此这些属性对无服务器云至关重要。另一方面,它们在数据中心中并没有那么明显有用,因为组件保持驻留可以提供性能优势,而不会产生增量的云服务费用。

微服务并非全是啤酒和玫瑰

“微服务”也许是云时代应用程序组件的所有新术语中最令人困惑的。谷歌倾向于使用这个术语来表示与函数大致相同的东西,但在开发人员中,这个术语似乎具有不同的含义。对于他们来说,微服务是一个小组件,它共享函数的无状态属性,但就像服务一样,它们是持久的。

“无服务器的函数”在使用结束后就结束,但微服务往往会部署并保留在原地以供连续使用。这使得它们成为服务和函数之间的一种方式,这可能就是为什么微服务似乎主导应用规划的原因。它们很容易接受,它们在云端和数据中心都很有用。

然而,微服务并非全是啤酒和玫瑰。将应用程序分解为可分发组件的任何策略都有其自身的风险。最明显的是,单独的组件意味着将工作从一个网络移动到另一个网络,这需要花费大量时间并产生连接丢失将导致应用程序故障的风险。

如果微服务小于服务,则会出现更多服务,从而导致更多的网络延迟和风险。如果申请没有经过精心设计,两者都会加剧。例如,与单个事务相关的十几次调用的微服务也会使延迟和风险增加十倍。最好避免使用可能存在这种迭代的微服务。

无服务器函数功能也可能被滥用。您只需支付在无服务器云应用程序中运行的内容,但是当您将函数功能用于不经常运行的内容时,这是最有价值的。如果一个函数每小时被调用数百次,那么它肯定会比它成为微服务时保持驻留时的成本更高 - 不如转成为微服务。

总结

组件化在开发和运行应用程序方面都有好处,但即使它已经存在了几十年,我们仍然在努力应对这些好处的不利因素。服务,微服务和函数功能都是构建基于组件的敏捷应用程序的方法,甚至这些术语对许多人来说都很困惑,这意味着在云时代构建应用程序需要特别小心。

 

                   

1