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