作者｜Astasia Myers译者｜无明编辑｜张婵2017 年对于DevOps来说是非常重要的一年，DevOps生态系统的用户数量有了长足的增长，CNCF 项目（Cloud Native Computing Foundation，2015 年 7 月成立，隶属于 Linux 基金会，初衷围绕“云原生”服务云计算，致力于维护和集成开源技术，支持编排容器化微服务架构应用）也在这一年横空出世。在接下来的一年，我们期望出现更多的创新和市场变化。
以下是我们对 2018 年微服务发展趋势的看法，包括服务网格 (service mesh)、事件驱动架构、原生容器安全、GraphQL和混沌工程。
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，用在更大规模的环境中。
从表面上看，混沌工程只是为了向系统注入混乱。尽管通过破坏系统来发现问题是件有趣的事情，但这样做并不一定会带来生产力的提升或者给我们提供有用的信息。实际上，混沌工程不只是注入故障那么简单，它还可以制造流量高峰、非正常的请求等，用以发现已经存在的问题。除了可以用它验证假设，还可用它来发现系统的新属性。通过发现系统弱点来改进系统弹性，以免造成糟糕的用户体验。
混沌工程通过对系统进行全面的测试来改善稳定性。随着工程师们在提升系统健壮性方面所做的工作越来越多，混沌工程似乎会变得越来越为人们所接受。
随着混沌工程成为主流，它可能会以开源项目的形式、商业的形式甚至是服务网格的形式来实现。