对于DevOps来说，2017年是重要的一年，在这一年中，DevOps生态的参与者人数持续增长，CNCF（云原生计算基金会）的项目增加了两倍。我们预计，在接下来的一年中，创新和市场调整能进一步加速这种增长趋势。以下是我们对2018年微服务趋势的总结：服务网格、事件驱动架构、容器原生安全性、GraphQL和混沌工程（Chaos Engineering）。
1. 服务网格很热门！
服务网格作为一个改善服务到服务通信的专用基础设施层，是云原生范畴中最热门的话题。随着容器愈加流行，服务拓扑也频繁变动，这就需要更好的网络性能。服务网格能够通过服务发现、路由、负载均衡、心跳检测和支持可观测性，帮助我们管理网络流量。服务网格试图为无规则的复杂的容器问题提供规范化的解决方案。
像HAproxy、Traefik和Nginx一类的负载均衡器已经开始将自己重新定位，作为Web应用中的数据层，由此显而易见，服务网格正越来越受欢迎。虽然至今我们还没有发现服务网格被广泛的部署，但我们明确的知道许多公司正在产品中使用服务网格这种技术。此外，服务网格并不是微服务或者Kubernetes环境专有的，它还可以应用到虚拟机和无服务器环境中。例如，美国国家生物技术信息中心并没有运行容器，但它仍可以使用Linkerd。
服务网格也可以用于混沌工程——“一门在分布式系统上进行实验的学科，目的是构建能够应对极端条件的可靠系统”。服务网格能够将延迟和错误注入到环境中，而不需要在每个主机上安装一个守护进程。
Istio和Buoyant 的 Linkerd 是该领域最引人注目的产品。值得注意的是，Buoyant去年12月份发布了针对Kubernetes的开源服务网格Conduit v0.1。
2. 事件驱动架构的崛起
随着对业务敏捷性需求的增加，我们开始看到向“推送”或者事件驱动架构转变的趋势——由一个服务发送事件，一个或多个观察者容器异步地响应事件，而不需要通知事件的生产者。与请求-响应架构不同，在事件驱动系统中，启动容器中的功能流程和事务不依赖于下游容器的远程进程的可用性和完成情况。这样做的另一个优点是，开发人员在设计各自的服务时可以更加独立。
虽然开发人员可以将容器环境设计为事件驱动，但本质上是FaaS（函数即服务）体现了事件驱动这一性质。在FaaS架构中，一个函数被作为文本保存在数据库中，等待被某一个事件触发。当函数被调用后，API controller接收消息，并通过负载均衡器将其发送到消息总线，消息总线将其放进队列中等待被调度并配置到调用者容器。执行完成后，结果被存储到数据库中，并发送给用户，与此同时，该函数被解除，直到被再次触发。
FaaS的好处包括：（1）缩短从编写代码到运行服务的时间，因为除了源码之外，不需要创建或推送任何组件，（2）开销减少，得益于像AWS Lambda这样的FaaS平台管理和扩展着函数。然而，FaaS也不是一颗完美的银弹。由于FaaS需要将每个服务解耦，因此可能存在大量函数难以被发现、管理、协调和监控。最终，如果没有包括依赖关系在内的全面可视化，调试FaaS系统将很困难，并且可能会出现死循环。
目前，在使用过长的调用链，需要将大量数据加载到内存中以及需要满足一致性的进程等这些场景中，FaaS并不适用。尽管开发人员通常只在后台作业和时间事件中使用FaaS，我们仍相信随着存储层的加速和平台性能的提高，FaaS的适用范围将随着时间的推移得到拓展。
2017年秋季，CNCF调查了550余人，其中31%使用无服务器技术，28%计划在未来18个月内使用无服务器技术。调查随后提到使用何种无服务器平台，77%回答是AWS Lambda。AWS Lambda可能是领先的无服务平台，然而，我们仍相信可能有很多有趣的机会。边缘计算（Edge Compute）对于物联网和AR/VR使用场景尤为重要。
3. 安全需求发生变化
由于内核访问控制，在默认情况下，容器中的应用基本上很安全。在虚拟机环境中，唯一可见的点是虚拟设备驱动程序。在容器环境中，操作系统拥有系统调用和语义。这意味着更加丰富的功能。在此之前，运营商通过向虚拟机中放置代理来完成其中某些功能，但这很复杂而且难于管理。容器提供了更清晰的可见性，并且与虚拟机环境相比，容器环境不需要集成多余的代理。
尽管如此，据一项调查显示，安全性是使用容器的最大障碍，也就是说，容器仍然存在安全问题。最初，漏洞是容器环境中的主要安全问题。随着即用型容器镜像数量的成倍增加，确保它们也没有漏洞变得非常重要。随着时间推移，扫描镜像和身份认证已经成为一种商品。
与虚拟机管理程序作为访问和控制点的虚拟化环境不同，任何可访问内核根目录的容器基本上都可以访问内核上的所有容器。反过来，组织必须保证容器与主机的交互的安全，以及控制哪些容器可以执行某些操作或系统调用。增强主机控制以确保正确配置组和命名空间对于维护安全性也很重要。
最后，传统的防火墙依赖IP地址规则来管理网络流量。该技术无法被扩展到容器环境中，因为动态协调器会复用IP。运行时安全检测和响应对于生产环境至关重要，它通过对容器环境进行指纹识别并构建详细的行为基线图像来实现，因此很容易检测到异常行为并对攻击者进行沙箱处理。上文提到的调查指出，52％接受调查的公司在生产环境中运行容器，这表明容器的运行时安全检测解决方案的正在加速发展。
4. 从REST迁移到GraphQL
GraphQL是一种满足查询需求的API规范，由Facebook在2012年创建，并于2015年开源。GraphQL类型系统允许开发人员自定义数据模式。可以添加新的字段，并可以在不影响现有查询或重构客户端应用程序的情况下对字段进行更新。GraphQL的强大在于它不需要绑定到特定的数据库或存储引擎。
GraphQL服务器作为一个独立的HTTP端点运行，能够表达服务的全部功能。通过在类型和字段上定义资源之间的关系（而不是像REST一样的端点），GraphQL可以追踪属性之间的引用，因此服务可以使用单个查询从多个数据源中获取数据。此外，REST API需要为单个请求加载多个URL，这导致网络请求增多，降低了查询速度。由于需要更少的通信次数，GraphQL减少了每个数据请求所需的资源数量。返回的数据通常格式化为JSON。
与REST API相比，GraphQL还有很多其他优点。首先，客户端和服务器是解耦的，因此可以独立地维护它们。与REST不同，GraphQL在客户机和服务器之间使用的语言非常类似，这使得调试更容易。查询语句的数据形式与从服务器获取的数据形式完全匹配，这使得GraphQL与SQL或Gremlin等其他语言相比更加高效和有效。查询语句反映了它们的响应的形式，因此可以检测到错误，并且可以识别出不能被正确解析的字段。更简单的查询使得整个进程的稳定性更强。众所周知，该规范支持外部api，而我们发现它也被用于内部api。
GraphQL的用户包括 Amplitude、Credit Karma、KLM、NY Times、Twitch、Yelp等。去年11月，Amazon通过推出支持GraphQL的AWS AppSync证明了GraphQL的流行程度。观察GraphQL将如何在gRPC和诸如Twitch的Twirp RPC框架这样的替代环境中发展，将会非常有趣。
5. 混沌工程愈发出名
混沌工程实验最初由Netflix推广，后来被亚马逊、谷歌、微软和Facebook实际应用，它在系统上实验，以提高解决生产问题的能力。混沌工程在过去的十年里不断发展。最初是从Chaos Monkeys开始——在生产环境中随机杀死某个服务，并且通过使用失败注入测试（FIT）和Chaos Kong扩展到更大的环境中。
表面上看来，混乱工程仅仅是注入故障。虽然破坏系统可能很有趣，但它并不总是有效或者能提供有用的信息。混沌工程包含了更广泛的范围，不仅仅是注入故障，还包括其他场景，如网络拥堵、异常请求组合等，来发现存在的问题。除了验证假设之外，它还应该能够揭示系统的新属性。通过发掘系统的弱点，团队可以提高系统的可伸缩性，防止客户的体验变差。
像神经网络和深度学习这样的复杂的新技术，与证明它们的有效性相比，证明它们为什么能够有效变得不那么重要。混沌工程通过对系统进行整体测试来识别不稳定性，从而帮助团队应对这一挑战。随着工程师们努力地使他们日益复杂的系统更加健壮，混沌工程可能会被普遍接受。
随着混沌工程变得越来越主流，它可以采用现有的开源项目、商业产品的形式，或者通过上文提到的服务网格来实现。
