【编者的话】在2017年，DevOps领域中增加了大量的生态系统玩家，那么2018年会有哪些变化呢？本文展望了微服务在2018年可能的5个发展趋势，并对各个趋势进行了详细的介绍。
对于DevOps来说，2017年是重要的一年，不仅生态系统玩家的数量大幅增加，而且CNCF项目增加了两倍。展望未来一年，我们期待创新和市场变化进一步加速。以下是我们对2018年微服务趋势的看法:服务网格、事件驱动架构、容器本地安全、GraphQL和混沌工程。
我们将关注这些趋势，以及未来一年将围绕它们建立业务的公司。你看到了什么趋势?在下面留言让我们知道哪些被遗漏了，或者如果你同意/不同意我们概述的内容。
1. 服务网格非常热门
服务网格是一个用于改进服务与服务之间的通信的基础架构层，也是目前最流行的原生云类别。随着容器变得越来越普遍，服务拓扑变得越来越动态，需要更先进的网络功能。服务网格可以通过服务发现、路由、负载均衡、健康检查和可观察性来帮助管理流量。服务网格试图驯服难以控制的容器复杂性。
随着像HAProxy、traefik和NGINX这样的负载均衡器开始重新定位为数据平面，它的服务网格变得越来越受欢迎。我们还没有看到广泛的部署，但确实知道在生产环境中运行服务网格的业务。此外，服务网格并不仅限于微服务或Kubernetes环境，还可以应用于VM和serverless环境。例如，国家生物技术信息中心不是运行容器，而是使用Linkerd。
服务网格也可用于混沌工程，“在分布式系统上进行实验的规程，以建立对系统抵御混乱状况能力的信心。”服务网格不需要在每个主机上安装一个守护进程，而是将延迟和失败注入到环境中。
Istio和Buoyant Linkerd是该领域最引人注目的产品。请注意，Buoyant在去年12月为Kubernetes提供的一个开源服务网格 Conduit v0.1。
2. 事件驱动架构的崛起
随着业务敏捷性需求的增加，我们开始看到一个向“推送”架构或者基于事件体系结构的发展趋势，即：一个服务发送一个事件，一个或多个观察者容器异步地运行逻辑来响应该事件，而不需要通知事件生产者。与请求-响应架构不同，在事件驱动的系统中，启动容器中的功能流程和事务负载并不依赖于下游容器中远程进程的可用性和完成情况。另一个好处是，在设计各自的服务时，开发人员可以更加独立。
虽然开发人员可以将容器环境构建为事件驱动架构，但功能即服务(FaaS)本身就体现了这种能力。在FaaS架构中，函数作为文本存储在数据库中，并通过事件触发。一旦调用了该函数，API控制器就会接收消息并通过负载均衡器将其发送到消息总线，消息总线将其排入计划并提供给一个调用容器。执行完后，结果存储在数据库中，并发送给用户，然后函数被分解，直到再次触发。
FaaS的好处包括: 1）从编写代码到运行服务的时间缩短了，因为创建或push源码之后不需要做额外操作。2）当函数由FaaS平台(如AWS)管理和缩放时，开销会减少。然而，FaaS并非没有自身的挑战。由于FaaS要求将服务的每个部分解耦，因此可能会出现难以发现、管理、编排和监视的函数的扩散。最后，如果没有依赖项的全面可视化工作，就很难调试FaaS系统，可能会出现无限循环。
目前，FaaS不适合需要长调用、加载大量数据到内存和强一致性能要求的进程。虽然开发人员使用FaaS进行后台工作和临时事件，但我们认为随着存储层加速和平台性能的提高，用例将随着时间的推移而扩展。
在2017年秋季，云计算基金会(CNCF)对550人进行了调查，其中31%使用serverless技术，28%计划在未来18个月内使用serverless。接下来的调查是询问哪个特定的服务器平台正在被使用。在使用serverless技术的169项中，有77%表示他们使用了AWS。虽然Lambda可能是领先的serverless平台，但我们相信在边缘需求中可能会有其他的机会。边缘计算对于物联网和AR/VR用例尤其有效。
3. 安全需要改变
由于内核访问控制，打包在容器中的应用程序从根本上更安全。在VM环境中，唯一可见的点是虚拟设备驱动程序。现在应用程序移动到容器环境，操作系统具有syscalls和semantic含义。这是一个更加丰富的信号。以前的操作符通过将代理放入VM来实现某些信号，但它比较复杂并且需要很多管理工作。容器环境下要提供清晰的可视化和集成功能，而这些工作量与VM环境工作量相比是微不足道的。
考虑到这一点，在451研究调查报告说，安全是容器应用的最大障碍——挑战依然存在！ 最初，漏洞是容器环境中的主要安全问题。随着公共注册中心中随时可用的容器映像的数量成倍增加，确保它们没有漏洞变得非常重要。人工处理、镜像扫描和授权认证已经成为一种常态处理方式。
与虚拟机管理程序作为访问和控制点的虚拟化环境不同，任何具有访问内核根的容器最终都可以访问内核上的所有容器。反过来，组织必须确保容器如何与宿主机交互，哪些容器可以执行某些操作或系统命令。增强主机控制以确保正确配置cgroups和namespace对于维护安全性也很重要。
最后，传统防火墙依靠IP地址规则来把关网络流。这种技术无法扩展到容器环境，因为动态编排器会复用IP地址。
运行时威胁检测和响应对生产环境至关重要，通过对容器环境进行指纹识别，并构建详细的行为基线图像，可以容易地检测到异常行为和攻击者的沙箱。一份451的研究报告指出，52%的被调查公司在生产环境中运行容器，这表明容器的运行时威胁检测解决方案正在加速发展。
4. 从REST转变到GraphQL
GraphQL是一种API规范，它是一种查询语言和一个运行时的查询执行操作。它由Facebook在2012年创建，并于2015年开源。GraphQL类型系统允许开发人员自定义数据模式。可以随时添加新的字段，并可以在不影响现有查询或重构客户端应用程序的情况下对字段进行更新。GraphQL是功能强大的，因为它没有绑定到特定的数据库或存储引擎。
GraphQL服务器作为一个单独的HTTP端点运行，它表示服务的全部功能。通过在类型和字段之间定义资源之间的关系(而不是像REST一样的端点)，GraphQL可以遵循属性之间的引用，因此服务可以使用单个查询从多个资源中接收数据。此外，REST api需要为单个请求加载多个url，这导致网络跳数增多，降低了查询速度。通过较少的通信次数，GraphQL减少了每个数据请求所需的资源数量，并且返回的数据通常格式化为JSON。
使用GraphQL可以获得比REST额外的好处。首先，客户端和服务器是解耦的，于是可以单独维护它们。与REST不同，GraphQL在客户机和服务器之间使用的语言非常类似，使得调试更容易。查询语句的数据形状与从服务器获取的数据的形状完全匹配，使得GraphQL比SQL或Gremlin等其他语言更加高效和有效。查询语句反映了它们的响应的形状，因此可以检测到偏差，并且不能正确解析的字段可以被识别。由于查询更简单，使得整个过程的稳定性更强。该规范最广为人知的是支持外部api，而我们发现它也被用于内部api。
GraphQL的用户包括 Amplitude, Credit Karma, KLM, NY Times, Twitch, Yelp等。在11月，Amazon通过推出AWS AppSync(包括GraphQL支持)证明了GraphQL的流行程度。观察GraphQL将如何在gRPC和诸如Twitch的Twirp RPC框架这样的替代环境中发展，将会非常有趣。
5. 混沌工程变得更加广为人知
最初由Netflix推广，后来被亚马逊(Amazon)、谷歌、微软(Microsoft)和Facebook应用，在系统上进行混沌工程实验，以提高其在生产问题上的确定性。混沌工程在过去的十年里不断发展。它从Chaos Monkeys开始，它们在生产环境中关闭了服务，并且扩展到更大的环境中使用失败注入测试(FIT)和Chaos Kong。
表面上看来，混乱工程仅仅是为了注入混乱。虽然破坏系统可能很有趣，但它并不总是有效或提供有用的信息。混沌工程包含了更广泛的范围，不仅仅是注入故障，还包括其他场景，如流量峰值、异常请求组合等，以发现现存的问题。除了验证假设之外，它还应该显示系统的新属性。通过发掘系统的弱点，团队可以帮助提高弹性，预防糟糕的客户体验。
像神经网络和深度学习这样的复杂的新技术，相比证明它们的有效性，理清它们的工作原理可能会变得不那么重要。混沌工程通过对系统进行整体测试来识别不稳定性，从而帮助应对这一挑战。随着工程师们努力使他们日益复杂的系统变得更加健壮，这可能会成为一种更为普遍的做法。
随着混沌工程变得越来越主流，它可以采用现有的开源项目、商业产品的形式，或者用上文提到的服务网格形式实现。
想要了解更多微服务知识的，可以关注我，最后给大家推荐一个交流学习群：650385180 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多，以下的课程体系图也是在群里获取。
