但可以在堆栈的最关键层减少风险 。 在目前的微服务架构中 。 代码包括HTTP服务器、TLS实现、主机运行时代码、系统接口和其他低层次的问题 。 除此之外 ， 由于开发者的代码是作为主机操作系统上的一个进程运行的 ， 所以开发人员也就要承担起进程安全的责任 。 还是以一种非常现实的方式 ， 毕竟当安全问题出现时 ， 进程是整个模型中最敏感的部分 。
换句话说 ， 突破进程、劫持SSL或访问系统文件往往会出现最严重的安全缺陷 。 而在目前的微服务模型中 ， 开发人员一般依靠外部库来处理这些问题 ， 并将这些库复制到自己的代码库中 ， 然后开发者负责在出现漏洞时做出反应 。 一般开发者对堆栈中最关进的部分都会采取这种做法 。 但开发者需要对堆栈这部分负责吗？目前还不清楚开发者是否真的需要负责 。
做好微服务的更好方法
微服务已经做的很不错了 。 把复杂的工作流程分解成更容易管理的小块 ， 也正确地考虑了关注点的分离 。 准确来说 ， 开发人员把任何特定单元的认识开销保持在相对较低的水平 。 反过来 ， 开发者也得到了很好的服务 。
相比之下 ， 上面看到的问题是低层次的问题 ， 它们的出现与开发人员做出的技术选择相关 ， 而且开发人员一般在很大程度上忽略了这些问题 。 不过 ， 可以从亚马逊的Lambda的功能即服务(FaaS)模型中找到一些替代方案来避免这些问题 。 FaaS承诺 ， 开发人员可以不用编写出一整个服务器 ， 而是只写一个处理函数就够 。 当收到输入指令时 ， 该函数将被执行 ， 并且只运行到它能产生输出就会被送回 。 这种模式就很令人舒服 ， 因为几乎没有“低级”代码需要管理 。
当然 ， FaaS并不是万能的 ， 它也存在问题 ， 首先 ， FaaS的实现是被平台约束的 。 亚马逊的FaaS和Azure的工作方式不同 ， 就导致你使用了FaaS就无法使用Azure 。 第二 ， 因为平台施加了限制 ， 所以FaaS能做的事情是有限的 。 不一定需要深入研究这些细节 ， 仅从表面上看 ， 由于FaaS的这些限制 ， 导致它与微服务相比 ， 使用限制相当明显 。
但如果把FaaS的强项移植到微服务模型上会怎样？能够为微服务架构建立一个更好的基础？如果看一下现在流行的网络框架 ， 会发现顶层模式是相当标准的将路由映射到处理函数中 。 在大多数情况下 ， 底层代码没有什么是真正需要开发者关注的 。 可能需要你去配置一些东西 ， 比如主机名或端口号什么的 。 但很少有人会从一个框架开始就花时间去修补HTTP或TLS的实现 。 因为从这开始 ， 就会为程序增加人外的代码数量 。 因此 ， 下一代微服务平台的逻辑位置就是消除基本的依赖关系 ， 让其工作时仅运行HTTP服务器 。 TLS、流程管理和基本路由 。
编写一个新的应用程序将从映射路由到处理函数开始 ， 而不是通过创建一个Web服务器 。 理想情况下 ， 这就是应用程序的安全边界运行的地方 。 开发人员将对代码和任何新依赖关系的安全负责 。 但该平台将保持较低的水平 ， 使其升级成为一个操作性问题 ， 而不是开发者的问题 。 最重要的是 ， 这意味着一个SSL补丁（例如）将不需要你重建、重新测试和重新发布你的应用程序 。 相反 ， 你只需要更新你的主机运行环境 ， 这通常可以在没有任何开发人员参与的情况下完成 。
像FaaS模型一样 ， 以这种方式编写的代码可以 "扩展为零" 。 这也就意味着 ， 当你的代码没有处理请求时 ， 它就不会运行 。 底层平台将一直在那里等待新的HTTP请求 。 但由于请求处理方法的安全边界存在 ， 导致多个应用程序可以使用同一个HTTP监听器 ， 反过来看 ， 意味着可以实现更高的密度 。 而在这种情况下 ， 这直接转化为计算需求 。