1. 服务网格白热化

服务网格是一个专注于服务间通信的基础设施层，也是目前最受关注的与云原生有关的话题。随着容器的普及，服务拓扑变得越来越动态化，这对网络功能提出了更多的要求。服务网格通过服务发现、路由、负载均衡、健康检测和可观察性来管理流量，简化容器与生俱来的复杂性。

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

服务网格还可以用在混沌工程中。服务网格可以给系统注入延迟和故障，这样就不需要在每台主机上安装后台进程。

Istio 和 Buoyant 的 Linkerd 是目前最为流行的服务网格框架。另外，Buoyant 在去年 12 月份开源了用于 Kubernetes 的服务网格框架 Conduit V0.1。

2. 事件驱动架构的崛起

随着业务场景的不断变化，我们已经看到了基于推送或事件的架构正在成为一种趋势。服务向订阅事件的观察者容器发送事件，容器异步做出响应，事件发送者可能对此一无所知。与请求响应式架构不同的是，在基于事件的系统架构中，发起事件的容器并不依赖下游的容器，它们的处理过程和加载的事务与下游容器的可用性或完成情况无关。这种架构的另一个好处是，开发者可以更加独立地设计各自的服务。

在容器环境中使用基于事件的架构时，功能即服务（FaaS）可以助他们一臂之力。在 FaaS 架构中，功能以文本的形式保存在数据库中，然后由事件来触发它们。在调用一个功能时，API 控制器会收到一个消息，并将它通过负载均衡器发送到消息总线，调用者容器负责处理队列中的消息。消息处理完毕后，结果被保存在数据库中，并发送给用户，而功能暂时退役，等待下一次触发。

FaaS 有两大好处。首先，缩短了服务开发时间，因为除了源代码，不需要创建其他任何东西。其次，降低了开销，因为功能的管理和伸缩通常是由 FaaS 平台（比如 AWS Lambda）来完成的。当然，采用 FaaS 本身也存在一些挑战。FaaS 要求解耦每一个服务，那么就会存在大量的服务需要发现、管理、编配和监控。因为缺乏对服务依赖链的全盘了解，FaaS 系统难以调试，而且可能会出现无限循环依赖问题。

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

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

3. 安全模型的变化

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

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

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

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

4. 从 REST 到 GraphQL

GraphQL 是 Facebook 于 2012 年创建并于 2015 年开源的一套查询语言 API 规范。GraphQL 的类型系统允许开发者自己定义数据 schema，可以增加新字段，也可以删除旧字段，这些都不会影响已有的查询，也不需要修改客户端。GraphQL 非常强大，因为它没有与特定的数据库或存储引擎绑定在一起。

GraphQL 服务器使用一个单独的端点来提供所有的功能。只要定义好资源之间类型和字段的关系（这个与 REST 端点不太一样），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 的发展真是一件有趣的事情。

5. 混沌工程浮出水面

混沌工程最初由 Netflix 发起，后来亚马逊、谷歌、微软和 Facebook 也开始实践。混沌工程的目的在于改进系统的确定性，以便应对生产环境的各种问题。混沌工程经历了十年的发展。最初，Netflix 开发了 Chaos Monkeys，用它在生产环境关闭部分服务，后来演变成故障注入测试和 Chaos Kong，用在更大规模的环境中。

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

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

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