服务发展趋势

在2017年，DevOps领域中增加了大量的生态系统玩家，那么2018年会有哪些变化呢？本文展望了微服务在2018年可能的5个发展趋势，并对各个趋势进行了详细的介绍。

对于DevOps来说，2017年是重要的一年，不仅生态系统玩家的数量大幅增加，而且CNCF项目增加了两倍。展望未来一年，我们期待创新和市场变化进一步加速。以下是我们对2018年微服务趋势的看法：服务网格、事件驱动架构、容器本地安全、GraphQL和混沌工程。

我们将关注这些趋势，以及未来一年将围绕它们建立业务的公司。你看到了什么趋势？在下面留言让我们知道哪些被遗漏了，或者如果你同意/不同意我们概述的内容。

服务网格非常热门

服务网格是一个用于改进服务与服务之间的通信的基础架构层，也是目前最流行的原生云类别。随着容器变得越来越普遍，服务拓扑变得越来越动态，需要更先进的网络功能。服务网格可以通过服务发现、路由、负载均衡、健康检查和可观察性来帮助管理流量。服务网格试图驯服难以控制的容器复杂性。

随着像HAProxy、Trfik和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用例尤其有效。

安全需要改变

由于内核访问控制，打包在容器中的应用程序从根本上更安全。在VM环境中，唯一可见的点是虚拟设备驱动程序。现在应用程序移动到容器环境，操作系统具有syscalls和semantic含义。这是一个更加丰富的信号。以前的操作符通过将代理放入VM来实现某些信号，但它比较复杂并且需要很多管理工作。容器环境下要提供清晰的可视化和集成功能，而这些工作量与VM环境工作量相比是微不足道的。

考虑到这一点，在451研究调查报告说，安全是容器应用的最大障碍——挑战依然存在！最初，漏洞是容器环境中的主要安全问题。随着公共注册中心中随时可用的容器映像的数量成倍增加，确保它们没有漏洞变得非常重要。人工处理、镜像扫描和授权认证已经成为一种常态处理方式。

与虚拟机管理程序作为访问和控制点的虚拟化环境不同，任何具有访问内核根的容器最终都可以访问内核上的所有容器。反过来，组织必须确保容器如何与宿主机交互，哪些容器可以执行某些操作或系统命令。增强主机控制以确保正确配置cgroups和namespace对于维护安全性也很重要。

最后，传统防火墙依靠IP地址规则来把关网络流。这种技术无法扩展到容器环境，因为动态编排器会复用IP地址。

运行时威胁检测和响应对生产环境至关重要，通过对容器环境进行指纹识别，并构建详细的行为基线图像，可以容易地检测到异常行为和攻击者的沙箱。一份451的研究报告指出，52%的被调查公司在生产环境中运行容器，这表明容器的运行时威胁检测解决方案正在加速发展。

从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框架这样的替代环境中发展，将会非常有趣。

混沌工程变得更加广为人知

最初由Netflix推广，后来被亚马逊（Amazon）、谷歌、微软（Microsoft）和Facebook应用，在系统上进行混沌工程实验，以提高其在生产问题上的确定性。混沌工程在过去的十年里不断发展。它从ChaosMonkeys开始，它们在生产环境中关闭了服务，并且扩展到更大的环境中使用失败注入测试（FIT）和ChaosKong。

表面上看来，混乱工程仅仅是为了注入混乱。虽然破坏系统可能很有趣，但它并不总是有效或提供有用的信息。混沌工程包含了更广泛的范围，不仅仅是注入故障，还包括其他场景，如流量峰值、异常请求组合等，以发现现存的问题。除了验证假设之外，它还应该显示系统的新属性。通过发掘系统的弱点，团队可以帮助提高弹性，预防糟糕的客户体验。

像神经网络和深度学习这样的复杂的新技术，相比证明它们的有效性，理清它们的工作原理可能会变得不那么重要。混沌工程通过对系统进行整体测试来识别不稳定性，从而帮助应对这一挑战。随着工程师们努力使他们日益复杂的系统变得更加健壮，这可能会成为一种更为普遍的做法。

随着混沌工程变得越来越主流，它可以采用现有的开源项目、商业产品的形式，或者用上文提到的服务网格形式实现。

推荐一个交流学习裙：685167672里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多：

世界总在不停地转动，技术也不断进化，客户服务和联络中心技术也随之日新月异。一项研究表明，92％的美国成年人拥有至少一台移动电话或智能手机，此外，45％的美国成年人都至少拥有一台平板电脑，这意味着呼叫中心和客户服务行业会发生深刻变化并影响深远。

相对来说，婴儿潮一代和第X代的文化通常偏好面对面的服务，而人口总额达7500万的Y世代人，他们的文化更倾向于通过电话或其他以技术为中心的渠道来进行客户服务。一些研究表明，越来越多的顾客青睐高效周到的客服方式，如全天候24/7的客户支持，即时掌握客户情况的客服代表，快速呼叫应答，按零接通话务员，回电请求选择以及预计等待时间等等。这一系列客户服务要素将继续在客户服务的演变和呼叫中心的工作重点中发挥作用。以下是一些未来客户服务正在兴起的趋势。

移动化：呼叫代表可随时随地访问

值得高兴的是，呼叫中心代表们越来越不会被限制在固定的办公桌前。通常在人们的脑海中，狭小的办公空隔间和响铃不停的电话才是呼叫中心的典型场景。然而，随着越来越多的呼叫中心开始迁移到云端，我们开始发现，呼叫中心业务代表的服务台和传统办公空间只会慢慢成为一种自由选择，而不是呼叫中心的标配。恰巧与移动技术的发展趋势相匹配，网真技术可以让呼叫中心业务代表连接到网络后立即被识别与定位，这也使呼叫代表能够自行决定他们认为当前任务的最佳沟通形式。

统一通信与“移动至上”的客户

毫无疑问，客户希望他们收到的信息在所有通信渠道中都是一致并且是个性化的。统一通信不仅有利于客户，还可以帮助客户服务代表和联络中心。客户关系管理（CRM）软件允许呼叫中心业务代表通过多种媒体和设备向客户和顾客发送各种通知和更新消息。如前面所提到的，随着智能手机用户数量的增加，客户整天都在各种设备之间来回切换。客户服务应该会越来越多地通过移动设备所支持的电话、文本、在线聊天等各种渠道来进行访问。另外，统一通信还有益于呼叫代表们的项目团队合作。联络中心和专家经常谈论有效沟通对于客户的重要性，其实对于呼叫中心工作人员来说，他们之间的内部有效沟通同样重要。

将所有内容发送到云端

越来越多的联络中心正在意识到基于云的呼叫中心技术平台的好处。行业专家还预计，云平台将成为默认的存储方式。根据Forrester Research的研究，16％的联络中心设备采购者表示他们计划要将其联络中心系统转移到云端。事实上，到2021年，基于云计算的联络中心市场预估价值约为156.7亿美元。基于云计算的解决方案不仅具有成本效益，而且还提供了诸多优势，如实时通信、简化流程、消息传送、完善的客户服务、卓越的客户管理等等。除了上文提到的通信统一之外，云本身似乎也正在朝统一平台迈进。统一的云平台集成了私有云和公有云的部署，从而为用户提供一个集中的、基于web的操作面板，可以用来安全地访问电子邮件、应用程序、文件以及其他必要报告。随着呼叫中心行业采用越来越先进的产品和功能，基于云的统一通信还能带来很多巨大好处， 如语音分析和商业智能。通过将大数据分析转移到云端，不仅可以降低维护和运营成本，还可以利用最新功能来加速数据转化为实际行动的进程。

随着消费者需求的变化，企业的要求也在发生变化。因此，未来对客户服务和联络中心机构的客服要求仍将不断提升。联络中心必须与当今客户的需要和需求保持一致，才能提供最佳的客户服务。

在2017年，DevOps领域中增加了大量的生态系统玩家，那么2018年会有哪些变化呢？本文展望了微服务在2018年可能的5个发展趋势，并对各个趋势进行了详细的介绍。

对于DevOps来说，2017年是重要的一年，不仅生态系统玩家的数量大幅增加，而且CNCF项目增加了两倍。展望未来一年，我们期待创新和市场变化进一步加速。以下是我们对2018年微服务趋势的看法：服务网格、事件驱动架构、容器本地安全、GraphQL和混沌工程。

我们将关注这些趋势，以及未来一年将围绕它们建立业务的公司。你看到了什么趋势？在下面留言让我们知道哪些被遗漏了，或者如果你同意/不同意我们概述的内容。

服务网格非常热门

服务网格是一个用于改进服务与服务之间的通信的基础架构层，也是目前最流行的原生云类别。随着容器变得越来越普遍，服务拓扑变得越来越动态，需要更先进的网络功能。服务网格可以通过服务发现、路由、负载均衡、健康检查和可观察性来帮助管理流量。服务网格试图驯服难以控制的容器复杂性。

随着像HAProxy、Trfik和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用例尤其有效。

安全需要改变

由于内核访问控制，打包在容器中的应用程序从根本上更安全。在VM环境中，唯一可见的点是虚拟设备驱动程序。现在应用程序移动到容器环境，操作系统具有syscalls和semantic含义。这是一个更加丰富的信号。以前的操作符通过将代理放入VM来实现某些信号，但它比较复杂并且需要很多管理工作。容器环境下要提供清晰的可视化和集成功能，而这些工作量与VM环境工作量相比是微不足道的。

考虑到这一点，在451研究调查报告说，安全是容器应用的最大障碍——挑战依然存在！最初，漏洞是容器环境中的主要安全问题。随着公共注册中心中随时可用的容器映像的数量成倍增加，确保它们没有漏洞变得非常重要。人工处理、镜像扫描和授权认证已经成为一种常态处理方式。

与虚拟机管理程序作为访问和控制点的虚拟化环境不同，任何具有访问内核根的容器最终都可以访问内核上的所有容器。反过来，组织必须确保容器如何与宿主机交互，哪些容器可以执行某些操作或系统命令。增强主机控制以确保正确配置cgroups和namespace对于维护安全性也很重要。

最后，传统防火墙依靠IP地址规则来把关网络流。这种技术无法扩展到容器环境，因为动态编排器会复用IP地址。

运行时威胁检测和响应对生产环境至关重要，通过对容器环境进行指纹识别，并构建详细的行为基线图像，可以容易地检测到异常行为和攻击者的沙箱。一份451的研究报告指出，52%的被调查公司在生产环境中运行容器，这表明容器的运行时威胁检测解决方案正在加速发展。

从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框架这样的替代环境中发展，将会非常有趣。

混沌工程变得更加广为人知

最初由Netflix推广，后来被亚马逊（Amazon）、谷歌、微软（Microsoft）和Facebook应用，在系统上进行混沌工程实验，以提高其在生产问题上的确定性。混沌工程在过去的十年里不断发展。它从ChaosMonkeys开始，它们在生产环境中关闭了服务，并且扩展到更大的环境中使用失败注入测试（FIT）和ChaosKong。

表面上看来，混乱工程仅仅是为了注入混乱。虽然破坏系统可能很有趣，但它并不总是有效或提供有用的信息。混沌工程包含了更广泛的范围，不仅仅是注入故障，还包括其他场景，如流量峰值、异常请求组合等，以发现现存的问题。除了验证假设之外，它还应该显示系统的新属性。通过发掘系统的弱点，团队可以帮助提高弹性，预防糟糕的客户体验。

像神经网络和深度学习这样的复杂的新技术，相比证明它们的有效性，理清它们的工作原理可能会变得不那么重要。混沌工程通过对系统进行整体测试来识别不稳定性，从而帮助应对这一挑战。随着工程师们努力使他们日益复杂的系统变得更加健壮，这可能会成为一种更为普遍的做法。

随着混沌工程变得越来越主流，它可以采用现有的开源项目、商业产品的形式，或者用上文提到的服务网格形式实现。

推荐一个交流学习裙：685167672里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多：