自单体数据中心以来，软件架构已经走过了漫长的道路，而且这种演变产生的术语比许多组织学习它们的速度更快。随着云计算正在推动软件变革，并成为企业IT计划中几乎普遍的一部分，我们需要了解云软件的结构。这意味着要学习其令人困惑的术语，这个过程因缺乏明确和公认的定义而受到阻碍。
没有哪个比我们引用分布式应用程序的自治组件的方式更明显。我们有“服务”，这个术语已有近十年的历史，但仍在使用中。我们有“微服务”，这肯定不仅仅是微小的服务; 我们有“函数”或“lambdas”，它们通常用于“无服务器”云计算。但有什么区别，我们为什么要关心？
从组件构建软件有三个目标，我们称之为“三个R”：
1. “reuse重用”，意味着可以实现一次常用函数功能并在需要时使用。
2. “redeployment重新部署”，意味着对应用程序的更改可以降低更少的部署中断，
3. “repair修复”意味着由于可用性和性能而更容易修复问题。
从一端到下一端
“服务”，原始的组件化战略，至今仍在使用。按照惯例，服务是执行某些特定业务的应用程序的功能组件。面向服务的应用程序可能具有“添加员工”，“付钱给员工”，“更改员工信息”等服务。业务活动，业务流程和业务事务决定了组件化。
显然，这些都是单个应用程序的组件（在我的示例中属于工资单/人员管理应用），虽然它们总体上比应用程序小，但它们实际上并不是很小，并且它们也不是特别容易重用。您无法轻松地将“付钱给员工”纳入客户资源管理应用程序或检查处理。
这些组件服务通常也以特定方式实施。它们是会持久状态数据的，意味着它们被假定为始终可用，并且是有状态的，这意味着它们在事务之间存储信息。前一种情况意味着它们不被使用时也会浪费云中的资源，因此而必须为这些服务组件始终在线可用而付费，虽然经常不被真正使用！同时，由于在多个事务之间存储信息，这是由状态的，就无法通过创建多个副本来共享负载来扩展性能，因为相同的信息不会存储在原件中的副本中。
“函数功能”是另外一种情况。函数是一个软件组件，其输出完全取决于输入; 没有内部存储或使用。Output = 2xInput1 + Input2 是一个非常简单的函数的示例。函数显然很小并且是通用的，因此您可以轻松地重用它们，并且因为输出只是输入的函数，所以您可以为函数的任何副本提供输入并获得相同的结果。这使它们具有完全可扩展性和弹性。由于无服务器计算仅在使用时才加载，因此这些属性对无服务器云至关重要。另一方面，它们在数据中心中并没有那么明显有用，因为组件保持驻留可以提供性能优势，而不会产生增量的云服务费用。
微服务并非全是啤酒和玫瑰
“微服务”也许是云时代应用程序组件的所有新术语中最令人困惑的。谷歌倾向于使用这个术语来表示与函数大致相同的东西，但在开发人员中，这个术语似乎具有不同的含义。对于他们来说，微服务是一个小组件，它共享函数的无状态属性，但就像服务一样，它们是持久的。
“无服务器的函数”在使用结束后就结束，但微服务往往会部署并保留在原地以供连续使用。这使得它们成为服务和函数之间的一种方式，这可能就是为什么微服务似乎主导应用规划的原因。它们很容易接受，它们在云端和数据中心都很有用。
然而，微服务并非全是啤酒和玫瑰。将应用程序分解为可分发组件的任何策略都有其自身的风险。最明显的是，单独的组件意味着将工作从一个网络移动到另一个网络，这需要花费大量时间并产生连接丢失将导致应用程序故障的风险。
如果微服务小于服务，则会出现更多服务，从而导致更多的网络延迟和风险。如果申请没有经过精心设计，两者都会加剧。例如，与单个事务相关的十几次调用的微服务也会使延迟和风险增加十倍。最好避免使用可能存在这种迭代的微服务。
无服务器函数功能也可能被滥用。您只需支付在无服务器云应用程序中运行的内容，但是当您将函数功能用于不经常运行的内容时，这是最有价值的。如果一个函数每小时被调用数百次，那么它肯定会比它成为微服务时保持驻留时的成本更高 - 不如转成为微服务。
总结
组件化在开发和运行应用程序方面都有好处，但即使它已经存在了几十年，我们仍然在努力应对这些好处的不利因素。服务，微服务和函数功能都是构建基于组件的敏捷应用程序的方法，甚至这些术语对许多人来说都很困惑，这意味着在云时代构建应用程序需要特别小心。