技术沙龙 | 邀您于8月25日与国美/AWS/转转三位专家共同讨论小顺序电商实战

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 中也很不错。

(责任编辑：admin)