整理 | 丁广辉 责编 | 张红月
出品 | CSDN（ID：CSDNnews）
如果从微服务的功能定义开始 ， 很可能把这种模式定义为通过网络进行通信的REST服务 。 但当谈到编写微服务的程序时 ， 有一个严峻的现实摆在面前 ， 创建微服务的第一步需要涉及大量的代码 。 虽然已经不在考虑这个问题 ， 仅仅是将这些代码的存在作为微服务是一个“框架”的理由 ， 却也因此忽略了它对开销、运行时间、要求、安全性、成本和可维护性的影响 。
Kubernetes并不能明显的减少微服务所需开销
当开始编写一个新微服务时 ， 第一步就是导入大量的代码 ， 将其分布在数百个不同的包中 。 安装一个极简的Node.js微服务框架时 ， ExpressJS会获取到100个依赖项 。 在能用该框架写出“Hello World”之前 ， 这些依赖项就是100个上游库 。 这些依赖关系 ， 在开始编码之前 ， 代码的最低起点是54,000行 ， 这还是对于最小化的框架而言 。 如果在向其中加入类似Locomotive这样的MVC层 ， 起始代码的数量就会跃迁至近22万行 。 这种情况并非是当你使用Java或Node.js时才会发生 ， 类似的情况在大多数编程语言中比比皆是 。
在此基础上 ， 在将“业务逻辑”分层在框架之上 。 与起始阶段的几万甚至几十万行代码相比 ， 业务逻辑那仅仅几千行的代码 ， 通常只是依赖关系上的一层皮毛 。
为了运行一个微服务 ， 需要从一个HTTP服务器开始 。 这个服务器上将只运行一个微服务 ， 并且需要一直运行 。 因此再生产中 ， 需要扩展到多个实例 ， 以便能够有效的处理故障情况和负载高峰 。
而代码行数的多少部分决定了需要什么样的计算资源 。 代码库越大 ， 内存和存储就会越多 ， 最终导致使用的CPU也越多 。 在现如今的云计算世界里 ， 这就直接转化为需要的计算单元的大小 。 然后 ， 考虑到每个计算实例的基本需求 ， 在将其乘以需要运行的副本数量 。 最后在考虑到一般应用的微服务的平均流量 ， 可以得出要支付的成本是以复制的方式保持一个完整的应用一直在运行 ， 即使它在大部分时间都处于空闲状态 。
这些都是传统微服务需要支付的开销 。 虽然Kubernetes帮助解决了运行时存在的问题 。 它的存在让不需要在每个虚拟机上运行一个微服务 ， 而是运行一些庞大的虚拟机 ， 让Kubernetes把负载分配给它们 。 但是需要支付的开销依然并没有减少 。 Kubernetes也从未表明它的核心价值是降低云计算成本 。 现在的情况是 ， 就算使用Kubernetes运行微服务 ， 依旧要拥有足够的计算能力 ， 来保持这些微服务一直运行 ， 无论它们是否收到请求 。
如果对经济性感兴趣 ， 如果对在生产中运行时省钱感兴趣 ， 即使只是对消耗更少的CPU和内存感兴趣 ， 那么现在也是时候挑战每个微服务都以数十万行的导入代码开始的想法了 。
但在理解这意味着什么之前 ， 可以从安全的角度来谈论它 ， 尽管也可以从开发者压力的角度来谈论它 。
安全可以更容易
在微服务开始时有50至100个依赖关系 ， 其中许多依赖关系都是跨领域的 。 这意味着并不直接使用它们 ， 它们是其他依赖关系的依赖 。 在你写下第一行代码开始 ， 就需要做好承担安全责任的准备 。 因为每当这些库中的一个漏洞被暴露出来 ， 或者发生了零日漏洞在上游库被修复的情况时 ， 开发者这些在依赖关系上编写应用程序的人就是那个修复或采取防御措施的人 。
【WebAssembly 开启微服务新时代】在传统的微服务架构中 ， 作为开发者要对安全操作的方面负责 。 而现在 ， 只要从其他来源导入代码 ， 安全操作这个问题就会存在 。 虽然通过使用其他库 ， 会获得很多好处 。 但在某种意义上 ， 必须接受这样一个事实：操作性问题的依赖关系安全性 ， 将永远成为开发者的关注点 ， 因为开发者是必须解决这个问题的人 。