本文讲的是业务逻辑的演进——从单体应用到微服务再到函数【译者的话】这篇文章介绍了业务逻辑从单体应用到微服务模式，再到事件驱动函数模型的进化过程。从原理上剖析了每一次进化的动机，为我们揭示了变化背后的深层次原因，非常具有启发性。
【上海站｜3天烧脑式Spring Cloud训练营】培训内容包括：DevOps、微服务、Spring Cloud、Eureka、Ribbon、Feign、Hystrix、Zuul、Spring Cloud Config、Spring Cloud Sleuth等。
基础技术在不断进步，正在促进事件驱动函数模型的发展，于此同时也在快速提升业务逻辑的时效。
更新：感谢读者的阅读和反馈, 关于这篇文章中阐述的观点，我在
microxchg录制了一个视频，大家可以点击
这里观看。
运行应用软件的目的在于提供某种业务价值。价值通过创建和使用业务逻辑来传递，以便它可以为一些用户提供服务。
从开始创建业务逻辑到最终交付，为用户提供服务之间的时间称之为时效
。提供业务价值的成本等于创建业务逻辑的成本与交付业务逻辑的成本之和。
过去成本高昂、效率是主要考虑因素，高
时效
被认为是常态。今天，随着技术进步和成本的降低，在竞争压力的推动下，组织在评估和优化企业流程的时候，
时效
正在成为主要考察指标。换句话说，为了提升投资回报率，您需要找到增加回报率的方法，提前获得回报或减少投资。
问题的核心在于，当成本占主导地位时，随着成本的降低和软件的影响力的增加，焦点必然转向早日得到回报。
随着技术在过去十年的发展，我们已经看到从单体应用程序到微型服务的发展，现在看到由
AWS Lambda
领导的无服务器架构、事件驱动函数模式的兴起。是什么因素推动了这种演变？低延迟消息传递使得从单体应用转到微服务，低延迟配置使得能够转移到Lambda。
在十年前，由于时间的限制，单体应用是交付业务逻辑的最佳方式。在五年前，由于限制因素的改变，微服务成为了最好的交付模式。新的应用程序开始建立在微服务架构上，而在过去的几年中，工具和开发实践已经全面支持微服务。时至今日，事件驱动函数模式再次发生了改变，因为潜在的限制已经发生变化，成本降低了，
时效
的根本改善也是可能的。
接下来，我们将详细介绍这种变化的不同维度：交付技术，硬件性能和组织架构实践，并了解它们如何结合起来推动这一变革。
在最开始的时候，交付成本是主要的考虑因素。采购、配置和部署硬件需要花费很长的时间，并且软件安装也是纯手动操作。为了优化交付，每个版本中包含大量业务逻辑，在这些业务逻辑上摊销过高的成本。与此同时，发布周期也不频繁，对于很多组织来说，
时效
通常数月有余。由于基础设施的变更交付周期很长，所以有必要提前预先提供额外的能力，这导致非常低的平均利用率。
降低交付成本的第一步将重点放在流程自动化上。许多组织开发了自定义脚本来部署新硬件、安装和更新应用程序。最终像Puppet和Chef这样常见的框架变得流行起来，“基础设施即代码”加速了更新的交付。DevOps运动开始于运营团队采用敏捷软件开发实践，并与开发人员紧密合作，以此将
时效
从几个月减少到几天。脚本可以改变已有的基础设施及应用，但快速增长的业务或具有不可预测的工作负载，正在努力寻求新的容量（译者注：这里的容量指的是新的计算资源），通过调用
Amazon EC2
弹性扩容API可以解决这个问题。当开发人员有能力使用Web服务直接自动化许多操作任务时，新一轮全新的DevOps即将到来。按需部署、按时付费的能力可以实现更高的平均利用率，并自动处理突然爆发的工作负载。
当Docker将容器变得“老少皆宜”时，另一波提升交付的浪潮来到了。Docker提供了一种方便的打包格式，这种格式包括一组固定的依赖关系，一个比进程隔离性更强、但弱于虚拟机的运行时环境。容器能够在秒级时间内启动，并且节省大量的内存占用空间。通过将许多容器打包到一个实例上，可以将运行时间从几个小时缩短到数分钟甚至数秒，资源利用率也大幅提升。基于容器的持续交付工具链也提升了开发人员的工作效率，缩短了交付时间。当有大量可预测的工作负载时，容器可以运行在高利用率水平，但是大多数时候工作负载是不可预测的，要么处于峰值要么处于低谷。例如，工作场所使用的应用程序只在一周168小时内的40个小时中使用。为了保持高可用性，通常将应用程序实例扩展到三个可用区域，甚至每个区域需要多个实例。因此一个服务最少需要六个实例。如果我们想缩容到0个实例，那么我们需要找到一种机制，在事件发生时启动应用的一个部分，当事件完成后则关停这部分应用。这是AWS Lambda功能的关键部分，它能在0.1秒的时间内对正在使用的计算资源进行扩容，并根据需要从零扩展到非常高的容量，从而保证峰值和低谷时的工作负载都是有效的100％利用率。从而没有必要考虑如何配置服务器，这就是为什么这通常被称为无服务器模式。
交付技术的进步为改进
时效
提供了垫脚石，但是在过去十年中，还有其他潜在的变化导致了最佳实践的一系列转型。
业务逻辑的大小取决于在满足服务延迟要求的条件下，计算资源（CPU/内存/网络/磁盘）的成本，以及访问相应资源的响应时间。
对于终端用户来说，对于业务逻辑响应时间的要求并没有太大变化。在过去十多年里，基础技术发生了翻天覆地的变化，然而对响应时间的感知和期望确一直基本没变。CPU的计算速度在过去十年中增长缓慢，时钟频率始终在几GHz左右，然而芯片缓存却增长很快，而且CPU核数也在不断增加。内存速度和大小的提升也较为缓慢。
网络现在的传输速度相当快了，常见的从1GBit到10GBit，再到现在的25GBit（正如James Hamilton在他的AWS re：Invent 2016主题演讲中所解释），而且软件协议的效率更高。当通常的做法是通过1GBit网络发送XML有效负载时，通信开销将业务逻辑限制在与大型单体服务共同位置，并直接连接到数据库。十年以后，在25GBit网络上的编码效率将提升一个数量级，这意味着通信成本会降低两个数量级以上。换句话说，十年前服务之间发送和处理一条消息的时间，如今可以达到100至1000条。这是从单体应用架构转移到其他架构模式的关键推动因素。
存储和数据库在过去十年中也经历了一场革命。单体应用将业务逻辑映射到基于复杂关系型数据库模式的事务，这些数据库模式链接了很多的表，并且提供统一的原子更新。十年前，最佳实践是通过存储区域网络建立少数的大型集中式关系数据库，这些数据库后端连接着价格昂贵的磁盘阵列，磁盘与数据库之间建立巨大的缓存池。
今天高速缓存的磁盘已被固态磁盘所取代。不同之处在于读取速度从缓慢、昂贵和不可预测（因为缓存命中率不一致）变得持续快速，且几乎无限制。由于磨损均衡算法和其他影响，写入和更新从缓存磁盘的快速迁移到固态磁盘的具有不可预测性。由于众多原因，新的“NoSQL”数据库架构已经变得流行，但我们关注的只有两点：简单的数据模型和充分利用了固态存储的优势。简单的模式强制将在同一关系数据库中链接在一起的数据表分离成多个独立的NoSQL数据库，从而推动业务逻辑的分散化。Amazon DynamoDB数据存储服务从一开始就设计为只在固态磁盘上运行，为请求提供极其一致的低延迟。Apache Cassandra的存储模型生成大量随机读取，并且很少进行大量写入，无更新，非常适合固态磁盘。与关系数据库相比，NoSQL数据库提供简单但极具成本效益，高可用性和可扩展性的数据库，并且具有非常低的延迟。NoSQL数据库的普及率快速增长是单体应用架构模式转移的另一个关键推动因素。其余关系型的主要模式被剔除，或者变得更容易扩展，并被迁移到诸如Amazon的RDS和Aurora之类的服务中。
当我们看IT的变化时，常常谈论“人，过程和技术”。我们刚刚看到技术如何将利用率和部署速度提高到了AWS Lambda的极限，在几分之一秒内实现了所部署的应用100％利用率。技术也将单体逻辑代码分解成数以百计的微服务/函数，并将单体的RDBMS拆分为许多简单可扩展和高可用性的NoSQL和关系数据存储。
过去十年，“人与过程”也发生了巨大变化。让我们考虑一下由100位开发人员组成的一个团队。为了协调，管理测试并且每隔几个月向这个“巨型逻辑”提交更新，通常有更多的人运行这个过程，而不是编写代码。通常需要两倍多的项目经理，测试人员，DBA，运维人员等。一成不变的组织架构，一切由各种工作任务单所驱动。管理的层次结构要求每个人写每周报告和参加许多汇报工作状态的会议，研发人员需要抽出时间来编码实际的业务逻辑！
DevOps实践，微服务架构和云部署三者与持续交付、紧凑的“
两个披萨团队
”模式紧密合作，大大减少了任务单，会议和管理成本。小团队的开发人员和产品经理在需要时独立地编写，测试和部署自己的微服务。开发人员的比率发生逆转，从原来的50个经理变为100个开发。每个开发者在会议中花更少的时间和等待任务单，这就获得了两倍的时间，而由此带来的
时效
提升可高达百倍。这个变化的最直观效果就是从做项目转向做产品。大量的项目经理被更少的产品经理所取代。在我所见过的某些案例中，150人输出了原来300多人工作成果的两倍。投资一半，但得到双倍回报，
时效
提升一百倍。许多组织一直在进行这种转型，并有类似改进的实例。
基于Lambda的应用程序由几乎完全是业务逻辑的单个事件驱动功能构成，并且有更少的模版化的内容和平台代码需要管理。这是早期的情况，但这似乎正在推动另一个根本性的变化。开发人员的小团队将在
短短几天内
从零开始就开始准备应用程序。他们正在使用短小精悍的功能和事件将强大的API驱动的数据存储和服务粘合在一起。已完成的应用程序已经具有高可用性和可扩展性，高利用率，低成本和快速部署。作为一个类比，考虑到一堆模型房子从一块粘土需要多长时间开始，而不是一堆乐高砖。如果有足够的时间，您可以使用这种“粘土”创造任何东西，它具有表现力和创造性，它甚至还可以反其道而行之，创造单体应用（俗称“
大泥巴球
”）。乐高砖组合在一起，构成了一个功能有限的，块状的模型房屋，在一定的时间内也是很容易扩展和修改的。此外，还有
其他的“砖块”有点像乐高砖
，但它们并不是主流，任何类型的基于“标准砖”的系统将比“定制粘土”快得多。如果开发人员的生产力能够提高一个数量级，那么我先前提到的100个开发人员的案例中，他们开发的单体应用可以重写，并且在几周之内被10名开发人员组成的团队所取代。如果你怀疑这是否会奏效，大可做一个实验来验证，这个实验的成本还是很低的。
事件驱动函数的调用延迟是限制复杂应用程序的关键限制之一，但随着时间的推移，这些延迟正在减少。
我真正的关注点在于已经存在的单体应用是应该
整体搬到云环境中
，还是应该重写这个应用这个决定性的ROI阀值。应用从数据中心上云的最佳实践是，将扩展性要求高和经常需要修改的单体应用重写成微服务，本身就很小的应用和很少需要修改的应用采取原封不动的策略。我认为AWS Lambda改变了这个决策方式，它会是新的、试验性质的应用的首选方式。这种方式很值得一试，因为可以做多次的重写。
我对您的经验非常感兴趣，请让我了解在您的环境中，您是如何看待
时效
的。
原文链接：Evolution of Business Logic from Monoliths through Microservices, to Functions （翻译：付辉）
原文发布时间为：2017-03-31
本文作者：付辉
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：业务逻辑的演进——从单体应用到微服务再到函数
