2018年的五大微服务

5 Microservices Trends to Watch in 2018

2017年是DevOps的重要一年，因为生态系统参与者数量大幅增长，CNCF项目增加了两倍。展望未来一年，预计创新和市场变化将进一步加速。 2018年微服务趋势：服务网格，事件驱动架构，容器本机安全性，GraphQL和混沌工程。

原文地址:链接

----------

热门的服务网格

很明显的，服务网格越来越受欢迎，随着 HAProxy、traefik 和 NGINX 开始把自己重新定位成数据平面。尽管服务网格还没有得到大规模部署，但确实也已经有些企业在生产环境中运行服务网格。此外，服务网格不仅可以在微服务或 Kubernetes 环境中使用，也可以被用在 VM 和无服务器架构的环境中。例如，美国国家生物技术信息中心没有使用容器，但他们使用了 Linkerd。

服务网格还可以用在混沌工程中。“在分布式系统上进行实验的学科，以建立对系统承受湍流条件的能力的信心。”而不是安装在每个主机上运行的守护进程，服务网格可以注入延迟和故障。

Istio 和 Buoyant 的 Linkerd 是该领域最引人注目的产品。而且特别注意，Buoyant 在去年 12 月份开源了用于 Kubernetes 的服务网格框架 Conduit V0.1。

----------

事件驱动架构的兴起

在容器环境中设计基于事件驱动的架构时，功能即服务（FaaS）可以助他们一臂之力。在 FaaS 架构中，函数以文本的形式保存在数据库中，然后由事件来触发它们。在调用一个函数时，API 控制器会收到一个消息，并将它通过负载均衡器发送到消息总线，消息总线将其队列等待调度并配置到调用程序容器。执行后，结果被保存在数据库中，并发送给用户，而功能将被解除，等待下一次触发。

FaaS的好处包括：

1. 缩短从编写代码到运行服务的时间，因为除了源代码，不需要创建其他任何东西。
2. 由于功能由AWS Lambda等FaaS平台管理和扩展，所以开销减少。

当然，采用 FaaS 本身也存在一些挑战。由于FaaS需要将每个服务分离(解耦)，那么就会存在大量的功能需要被发现、管理、编配和监控。最后，如果缺乏对服务依赖的全盘了解，很难调试FaaS系统，而且可能会出现无限循环依赖问题。

在目前看来，FaaS 并不适用于那些需要较长处理时间、需要往内存里加载大量数据或需要稳定性能的场景。开发者主要使用 FaaS 来运行后台作业和处理临时事件，不过我们相信，随着存储层速度的加快和平台性能的提升，FaaS 的应用场景会越来越多。

2017 年秋天，云原生计算基金会（CNCF）对 550 名用户进行了问卷调查，其中 31% 的人正在使用无服务器架构技术，28% 的人打算在未来 18 个月使用无服务器架构技术。在使用无服务器架构技术的 169 人当中，有 77% 使用的是 AWS Lambda。虽说 Lambda 或许是领先的无服务器架构平台，但我们相信边缘计算仍然有机会。边缘计算将在物联网和 AR/VR 用例尤为强大。

安全模型的变化

因为对内核访问方面的限制，部署在容器中的应用程序相对安全。在 VM 环境中，虚拟设备驱动器是唯一暴露可见性的地方。而在容器环境里，操作系统提供了系统调用，信号源也变得更加丰富。之前，管理员需要在 VM 中安装代理，但那样太复杂了，需要管理太多的东西。容器提供了更清晰的可见性，相比 VM，与容器的集成会更加容易。

考虑到这一点，451 Research公司发布的一份调查报告表明，安全性是影响容器普及的最大障碍。在一开始，安全漏洞就已成为容器环境最主要的问题。随着越来越多的容器镜像的发布，确保这些镜像不含有漏洞便成为当务之急。随着时间的推移，容器镜像扫描和认证成为了一种有利可图的生意。

在 VM 环境中，hypervisor 扮演着访问控制点的角色，而对于一个具备内核访问权限的容器来说，它可以访问内核上的其他所有容器。因此，使用容器的企业必须限制容器与宿主机之间的交互行为以及容器将会执行的系统调用。确保宿主机的 cgroup 和 namespace 配置妥当也是非常重要的一点。

传统的防火墙通过 IP 地址规则来控制网络流量。不过，这种技术无法在容器环境中使用，因为动态编配需要重用 IP。在生产环境，运行时攻击检测是非常关键的安全手段，通过构建容器指纹和定义行为基准，就可以很容易检测出异常行为，并把攻击者隔离在沙箱中。451 Research 公司的报告指出，受调的 52% 企业在生产环境中使用了容器，暗示采用集装箱本地运行的威胁检测解决方案业务的加速。

----------

从 REST 到 GraphQL

GraphQL 服务器使用一个单独的端点来提供所有的功能。只要定义好资源之间类型和字段的关系，GraphQL 就可以跟踪属性之间的关系，在单个查询中从多个资源获取数据。在使用 REST 时，可能需要为单个请求加载多个 URL，这样不仅增加了网络跳转，还拖慢了查询速度。通过减少网络跳转，GraphQL 降低了单个数据请求所要耗费的资源。GraphQL 返回的数据通常是 JSON 格式。

使用 GraphQL 还有其他好处。首先，客户端和服务器端之间解耦开了，这样就可以分开维护。GraphQL 使用相似的语言进行客户端与服务器端之间的通信，所以调试更加容易了。查询结构与服务器端返回的数据结构完全匹配，因此，相比其他语言，如 SQL 或 Gremlin，GraphQL 更加高效。查询本身就反映了响应消息的结构，所以可以很容易地检测出差异，如果没有正确处理某些字段也可以很容易识别出来。因为查询更简单了，整个流程也变得更稳定。虽然说 GraphQL 规范主打支持外部 API，但我们发现将它用在内部 API 中也很不错。

GraphQL 的用户包括 Amplitude、Credit Karma、KLM、纽约时报、Twitch、Yelp 等。去年 11 月，亚马逊推出的 AppSync 就提供了 GraphQL 支持，可见它有多么流行。在存在 gRPC 和 Twitch Twirp 这些 RPC 框架的前提下，看着 GraphQL 的发展真是一件有趣的事情。

----------

混沌工程变得更加知名。

从表面上看，混沌工程只是为了向系统注入混乱。尽管通过破坏系统来发现问题是件有趣的事情，但这样做并不一定会带来生产力的提升或者给我们提供有用的信息。实际上，混沌工程不只是注入故障那么简单，它还可以制造流量高峰、非正常的请求等，用以发现已经存在的问题。除了可以用它验证假设，还可用它来发现系统的新属性。通过发现系统弱点来改进系统弹性，以免造成糟糕的用户体验。

混沌工程通过对系统进行全面的测试来改善稳定性。随着工程师们在提升系统健壮性方面所做的工作越来越多，混沌工程似乎会变得越来越为人们所接受。

随着混沌工程成为主流，它可能会以开源项目的形式、商业的形式甚至是服务网格的形式来实现。