身份认证云本质上是一种“无服务器”应用,今天,我们就来讨论下这种模式的优点和缺点。如果没有权衡利弊,你或许不会使用身份认证云或其他“无服务器应用”。
先看一下“无服务器架构”的介绍:
无服务器架构是包含 BaaS (后端即服务)和 FaaS (函数即服务)的程序开发 /部署方案(但未来远不止如此)。这类结构消除了对传统服务器的管理需求,使用无服务器架构可以显著降低运营成本、复杂性和开发时间。相应的代价是对供应商有更强的依赖性。
身份认证云是无服务器架构的一个分支,使用身份认证云和使用无服务器架构拥有一样的好处。
身份认证云本质上是一种外包解决方案,这种方案就是向某人付费以管理身份认证这个过程。由于一个服务同时被上千人使用,所以会产生一种规模经济效应:你所需支付的费用非常少,因为和其他人共享了基础设施(硬件、网络)。
除了与他人共享基础设施外,你还可以省掉大量的人工成本,不必开发基础设施,从而快速进入核心业务的开发。
如果说 PaaS 是为你解决了硬件和资源层的抽象,那么 Serverless 则是为你解决了软件层的抽象,这样你可以更加专注于市场和产品。
身份认证虽然听上去很简单,但他包括了注册、登录、密码管理、非法探测以及其他登录方式(如 OAuth,小程序扫码),而这些功能在大多数应用中都是相似的。Authing 便是应此而生的,我们希望将现成的身份认证功能集成到应用程序中,而不用每次开一个新项目都去重复开发相似的功能,这不仅浪费资源还浪费时间。
另一个例子是 BaaS 数据库,如 Firebase。这源于一些团队发现客户端与数据库的连接完全可以从业务中剥离出来。BaaS 不仅消除了大部分数据库管理开销,也提供了 ACL 访问权限机制,这样能保证足够的安全性。
不可否认的是,没有一家公司仅能靠自己的代码开发出成功的产品。将自己的非核心业务通过云的方式托管到第三方服务上,不失为一个好的选择。
无服务器或 FaaS 最大的优势是其无限弹性拓展能力,而这带给你的最大好处是只需要支付所需的计算费用,不用支付为保障弹性伸缩而配置的其他计算资源。假设你在推广一个 APP,当峰值来临的时候,登录接口挂掉,新用户无法注册,这会对你的业务造成致命的打击。而使用 Authing 这种身份认证云的时候,你则完全不用操心,因为系统会在峰值时自动伸缩。
上图的红线是你在自己做弹性伸缩时所需要的服务器数量,蓝线是使用 Authing 时所需要的服务器数量,线的高度越低,所需支付的费用就越少。比起闲置的红线,蓝线明显更加绿色节能,这对厂商和消费者来说都是好事。
大公司的服务器集群利用率仅有 5%-15%。
而使用无服务器应用后能显著提高资源利用率。
合格的的无服务器应用都会配备强大的管理界面,这些界面能让你更容易的管理数据,拥有这些也不需要编写任何代码。
说完了优点,让我们看看缺点。
任何云服务,都有系统停机、成本变化、功能丧失或强制升级等问题( Authing 自然不会例外),用户在这种情况下只能十分被动的接受。如果处理不及时,可能会造成一定损失。
多租户问题指所有的认证请求都在同一批机器上,可能会引发由于交叉验证而产生的 BUG,这可能会间接影响到其他用户。这些 BUG 包括:安全问题(如一个客户能看到另一个客户的数据)、稳定性问题(一个客户产生的数据错误引发另一个客户的数据发生错误)和性能问题(一个高负载客户导致其他人减速)。
一旦你长时间使用 Authing,你可能会对 Authing 产生依赖,这时你在升级设计或架构时可能会遇到一些麻烦。
尽管身份认证云如今还不完美(因为他正处于一个青少年时期),但他的魅力已经开始展现。未来几年一定还会取得其他有趣进展,总有一天身份认证上云将会进入我们的架构工具包。
Authing 提供专业的身份认证和授权服务。
我们为开发者和企业提供用以保证应用程序安全所需的认证模块,这让开发人员无需成为安全专家。
你可以将任意平台的应用接入到 Authing(无论是新开发的应用还是老应用都可以),同时你还可以自定义应用程序的登录方式(如:邮箱/密码、短信/验证码、扫码登录等)。
你可以根据你使用的技术,来选择我们的 SDK 或调用相关 API 来接入你的应用。当用户发起授权请求时,Authing 会帮助你认证他们的身份和返回必要的用户信息到你的应用中。
<div align=center>Authing 在应用交互中的位置</div>
Demo: