Serverless架构或Serverless计算是软件架构风格向分布式系统发展结果，而当前建立一个系统的标准是面向服务架构(SOA)或者是SOA之微服务架构。

在微服务架构中，应用/服务被开发出来然后部署，每个服务组相关一些函数，在Serverless架构中，函数是被开发并部署到独立的平台，这个平台会照顾执行这些函数响应一些事件，举例：当有HTTP请求访问时，也许有一个函数计算计算出一个响应结果，或当一些东西写入到数据库式，会有一个专门函数来执行。

乍一看，这就让人想起了传统的存储过程，与存储过程相反，Serverless架构中的函数不仅仅限制于数据库操作事件，每个函数能够被不同编程语言实现，更远，也没有保证同样函数总是在同一个服务器上运行。

下面看看Serverless的目标和优缺点权衡。

低运营成本
微服务架构中的服务需要一直运行，实际上，在高负载情况下每个服务都不止一个实例，这样才能完成高可用性，在Serverless架构中则是没有事件发生时不会有服务运行，主机平台会只有在需要时才会执行相应的函数，按照云计算pay-as-you-go原则，如果没有东西运行，你就不必付款。

在Serverless架构中，扩展和自动扩展是没有问题的，当负载增加，会让受影响的函数以并行方式运行得更频繁。

弹性配置也在Serverless架构中很有效率，对于传统的云计算环境你会说：
“我愿意买3G内存，然后以后暂时就不需要再扩展了”。
而现在你会说：
“我会为X类型的30000个事件付费，为Y类型的5000个事件付费，然后以后暂时就不需要再扩展了”。

很明显，Serverless计算针对资源的使用是有效率的，特别具有运营的可操作性。

风险1：厂商锁定
平台会提供Serverless架构给大玩家，比如AWS Lambda，运行它需要使用AWS指定的服务，比如API网关，DynamoDB，S3等等，一旦你在这些服务上开发一个复杂系统，你会粘牢AWS，以后只好任由他们涨价定价了。

复杂性和低聚合
多少年来，软件工程师为高聚合和低复杂性奋斗，领域驱动设计和微服务是完美的配合，因为他们总结过去多少年的软件工程经验。

如果开发者忽视这些经验教训是会有风险的，特别是在构建Serverless架构时，它们会遭遇不可维护的函数地狱，在这个情况下，低运营成本优势也许会被更高维护成本超过。

转载：http://www.jdon.com/48121