最近，系统设计中较新颖的概念之一要属“无服务器架构”理念。毫无疑问, 这有点夸张, 因为确实有服务器参与其中, 但这意味着我们可以以不同的方式看待服务器。
无服务器的潜在上升空间
想象一下，一个简单的基于Web的应用程序，处理来自HTTP客户端的请求。而不是让一些程序运行时等待请求到达，然后调用一个函数来处理它们，如果我们可以按需启动运行每个函数，然后将其丢弃，那会怎样？我们不需要担心可以接受连接的运行的服务器数量，或者在伸缩时处理复杂的配置管理系统以构建应用程序的新实例。此外，我们还将减少诸如内存泄漏、分段错误等状态管理的常见问题。
或许最重要的一点是，这种按需调用函数的方法将允许我们伸缩每个函数，以匹配请求数并对它们并行处理。每个“客户”都将获得一个专门的流程来处理他们的请求，而流程数只会受到您处理的计算能力的限制。当与一个大型云提供商耦合，其可用的计算大大超过您的使用量，此时无服务器就有可能移除大量的复杂性，从而伸缩应用程序。
潜在的缺点
诚然, 在为每个请求构建进程时, 仍存在增加的滞后时间的挑战。无服务器永远不会像预先分配的进程和内存那样样快；然而,问题不在于它是否更快, 而在于它是否足够快。从理论上讲, 我们会接受无服务器的延迟, 因为我们会得到回报。然而, 这一权衡需建立在对手头的情况进行仔细评估的基础上。
使用Rancher和开源工具实现无服务器
Docker为我们提供了很多工具来实现这个无服务器的概念，并在最近的DockerCon上给出了很好的演示。Rancher将这些能力最大化了。因为我们的平台承担您的容器基础架构的管理，所以只需操作一个API即可添加和删除计算容量。通过软件定义栈的这部分能力，支持用户实现全面的应用程序自动化。
栈中的下一层即为无服务器系统编写代码的可用框架。您可以自己编写、或者扩展一些中间件来处理这个问题，但有很多开源项目提供了工具来简化这一过程。其中一个项目是Iron.io的Iron功能。我在Rancher上做了一个快速的POC，发现它很容易使用。使用这些compose文件可以在Rancher中快速启动该设置。
要使用这些文件，请将repo中的docker-compose.yml和rancher-compose.yml文件复制并粘贴到Rancher UI的“Add Stack（添加栈）”部分。或者从Rancher CLI中，简单地运行“rancher up”（确保设置以下环境变量：RANCHER_URL，RANCHER_ACCESS_KEY，RANCHER_SECRET_KEY）。
栈启动时，您应该可以在Rancher UI中看到。此外，您可以通过单击栈中第一个项目(“API - lb”)旁边的“i”图标，查找 Iron Functions API端点和UI的URL。
![wKiom1kjx1WwvgYsAAGE29YjGWs026.png]( "1.png")
部署完成后运行无服务器栈
![wKioL1kjx2_SonuAAAEBSCrPAPA338.png]( "2.png")
找到您的IronFunctions端点的URL
一旦您运行栈，请按照Iron.io的Github repo上的“Write a Function（编写一个函数）”的说明进行操作。您可能需要一些时间来适应，因为这需要您在编写应用程序时稍作改变。将不会有任何共享的状态供您的函数引用，而库之类的东西利用起来可能会又困难又昂贵。在我的例子中，我从Iron.io中选择了一个简单的golang函数：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
package
main
import
(
"encoding/json"
"fmt"
"os"
)
type Person struct {
Name string
}
func main() {
p := &Person{Name:
"World"
}
json.NewDecoder(os.Stdin).Decode(p)
fmt.Printf(
"Hello %v!"
, p.Name)
}
|
下一步是将函数部署到我们在Rancher中设置的Iron函数的实例中。为了使这更容易尝试，我编写了一个为您执行所有步骤的脚本。参照这个repo中的README。一旦部署了函数，您应该能够在UI中看到它，然后就可以试着用它了：
![wKiom1kjx7SAVk-LAADHFDjrtqw528.png]( "3.png")
IronFunctions的Dashboard
![wKioL1kjx86AEG5BAAC_aJ6gzTM914.png]( "4.png")
你的正在执行的函数的结果
从Rancher内部，您可以根据您的需求扩张或缩减员工人数。Rancher会把它们放在一个主机上，并将它们连接到一个负载均衡器上。根据最佳实践指南，您可以简单地根据“wait_time”度量，从而使伸缩操作相对简单。
若您也想过用这种方式构建应用程序，我觉得本文的教程会是一个很有用的尝试。如果您对此有任何意见或反馈，不要犹豫，联系我们！我们一如既往地期待听到您的反馈！
本文转自 RancherLabs 51CTO博客，原文链接:http://blog.51cto.com/12462495/1928533
