论无服务器架构的特征
Jan Stenberg
讲述：初明明大小：4.18M时长：04:33
Thoughtworks 首席开发者怀森·塔纳萨（Wisen Tanasa）在最近的博文当中提到，在目前关于无服务器架构的文献当中，有相当一部分由云服务供应商提供赞助，因此在内容上存在单纯强调优势的倾向。但塔纳萨认为，每当有新的技术出现时，最重要的是全面了解其意义，因此我们应该从客观角度出发探讨无服务器架构的特性。
塔纳萨表示他更倾向于使用“特质（trait）”、而非特性，因为他认为这些属于无服务器架构的固有元素，我们无法像处理其它可塑特性那样做出调整。特质是天然存在的，所以我们必须接受，而非与其针锋相对。
无服务器架构拥有较低的入门门槛，通过教程就可以轻松上手。但塔纳萨指出，虽然开发人员面对的初步学习曲线比较平缓，但随着项目变得更为复杂，曲线也会迅速呈现出陡峭的态势。在无服务器的世界中，代码、日志记录以及监控等基础设施仍然必不可少。此外，开发人员在面对无服务器架构时往往有忽略代码设计的倾向这是不对的。无论是 SOLID 这类设计概念，还是持续交付原则，都将在无服务器领域继续发挥重要作用。
在无服务器的世界里，不存在主机的概念，由此带来的一大优势，就是显著减少了运营开销。但与此同时，我们需要对应用程序中的不同度量标准进行监控，换言之我们必须重新学习如何调整整个架构。塔纳萨强调称，尽管能够自动添加安全补丁，但应用程序安全实践在无服务器环境仍然适用。
函数即服务（FaaS）具有临时性，这意味着无服务器本身是无状态的。由于状态不会被存储在应用程序当中，因此横向扩展就变得非常简单。另外，无状态也意味着发生错误的空间大大减少。但是，无状态也意味着我们无法利用众多有状态技术进行应用程序开发。
再有，无主机也意味着架构本身具有弹性。换言之，我们不必手动管理资源，资源分配方面的很多原有难题也将随之消失。一般来讲，这还意味着我们只需要为实际使用的资源付费。但在与遗留系统相集成时，这种弹性也有可能带来新的挑战。除非传统系统能够像无服务器组件那样轻松扩展，否则我们必须限制负载以防止其因过载而发生故障。
在默认情况下，无服务器架构当中包含大量通过网络进行分布式集成的组件。持久性由后端即服务（BaaS）负责实现，代码则以多项函数的形式运行，其它服务用于实现身份验证与队列等功能。分布式特质也为架构带来了高可用性。如果当前可用区存在问题，则架构可以使用另一可用区。不过分布式应用程序在一致性方面需要做出权衡，最典型的两种选项就是写入后读取以及最终一致性；我们在更新以及读取数据时，必须考虑到这些具体情况。
由于利用后端即服务支持事件，因此无服务器架构还具有事件驱动特质。这并不是说开发者必须完全接受事件驱动型架构，但事件驱动确实能够带来诸多优势，比如能够显著降低各组件之间的耦合水平。但这同时也会带来无法建立系统整体视图的风险，并提高排除系统故障的难度。
塔纳萨指出，无服务器架构带来了一种有趣的范式转变。其改进了软件开发当中的诸多方法，同时也引入了一系列需要由开发人员以及团队加以适应的全新挑战。
在另外两篇博文中，来自 Symphonia 公司的迈克·罗伯茨（Mike Roberts）描述了他对于无服务器的定义。在他看来，无服务器应用程序是一类利用无服务器服务实现的应用程序，且此类服务必须具有以下五点共通特质：
不需要管理服务器主机或者服务器进程。
根据负载进行自动规模伸缩与自动配置。
根据使用情况决定实际成本。
性能容量以不同于主机规模或数量的其它术语进行定义。
具备隐含的高可用性。
另外，在 2017 年的一篇博文中，Martin Fowler 提到了事件通知的风险，并指出虽然事件通知模式非常实用，但也增加了大规模流量长期处于监控之外的风险。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论