2018年5大微服务发展趋势

 

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，用在更大规模的环境中。

从表面上看，混沌工程只是为了向系统注入混乱。尽管经过破坏系统来发现问题是件有趣的事情，但这样作并不必定会带来生产力的提高或者给咱们提供有用的信息。实际上，混沌工程不仅是注入故障那么简单，它还能够制造流量高峰、非正常的请求等，用以发现已经存在的问题。除了能够用它验证假设，还可用它来发现系统的新属性。经过发现系统弱点来改进系统弹性，以避免形成糟糕的用户体验。

混沌工程经过对系统进行全面的测试来改善稳定性。随着工程师们在提高系统健壮性方面所作的工做愈来愈多，混沌工程彷佛会变得愈来愈为人们所接受。

随着混沌工程成为主流，它可能会以开源项目的形式、商业的形式甚至是服务网格的形式来实现。