边缘服务的一致性、耦合和复杂性( 二 )

【边缘服务的一致性、耦合和复杂性】新的用户需求(如增加额外的数据字段)可能需要前端和后端都作出修改，这是导致紧密耦合的根本原因。团队之间的紧密耦合降低了开发速度，这个可以用康威定律来解释。
跨团队的沟通成本要高于单个团队内部的沟通成本。同时拥有前端和后端开发人员的团队也可能缺乏效率。虽然从理论上讲，前后端开发人员处在同一个团队中，但在前端和后端开发人员之间仍然存在分界线。这种“隐式”的子团队隐藏了软件开发的一些复杂性，可以说是康威定律的一个不成文的补充。
当后端服务和前端应用程序发生紧密耦合时，发布管理也会变得复杂。微服务的最大优势之一是你不必一次性发布所有的内容，但紧密耦合的组件通常需要在同一时间发布，如果一个组件需要回滚，其他组件也都需要回滚。
GraphQLAPI设计
2015年， Facebook采用了一种不一样的API设计方法，即图查询语言(GQL)或GraphQL 。它是一种包含层次结构类型的模式，该模式包含三种特殊类型：查询、变异和订阅。调用者发送一个命令，该命令提供查询条件，并指定在响应中期望得到的数据格式。
最为流行、功能齐全且成熟的GraphQL服务器端框架实现是由旧金山的一家名为Apollo的小型初创公司开发的。有了他们的框架，在客户端增加新功能就变得非常容易，且无需对服务器作出大量修改。
后端开发人员必须编写schema和解析器。框架调用在请求中指定的解析器，然后将每个解析器的响应拼接在一起。

文章图片
类似的基本新闻提要的GraphQLschema 。
由于解析器位于属性级别，而且获取底层数据的机制可能一次性获取多个属性，因此存在重复获取相同数据的可能性，造成了浪费。这就是所谓的N+1问题。后端代码应该用某种类型的请求缓存来缓解这个问题。
基于生存时间值(TTL)、最近最少使用原则(LRU)的缓存在GQL中的作用是有限的。因为有效载荷是可以灵活指定的，所以很难实现高命中率和低脏读率的高效缓存。因此， GQL缓存往往要比RESTful缓存大得多。 ApolloGraphQL框架支持在schema中使用缓存提示注解或在解析器中动态设置，这可以通过浏览器端缓存或内存缓存或外部缓存(如Memcached或Redis)来实现。
变异部分与RPC相似，对于它们的处理方式并没有定义好的标准，所以它们都不好理解。
在撰写本文时， GraphQL的应用程序性能监控(APM)还没有RESTfulAPI那么成熟。 GraphQL没有提供内建支持，但有一些插件或解决方案可用于NewRelic、DataDog、Prometheus和AppDynamics 。我相信，随着时间的推移， Apollo风格的GraphQLAPM监控将变得更加主流。
在RESTfulAPI中，客户端指定路径，可能是查询字符串参数，可能是身份验证，仅此而已。而在GQL中，客户端必须指定有效载荷是什么样子的。这种小程序增加了调用GQL服务的复杂性，从而增加了出现错误的可能性。这也提高了自动化测试的成本。通常的方法是在测试自动化中查询所有的内容，这样做应该足够了，除非解析器需要通过上下文对象交换带外数据。
关注点分离
API设计该基于REST还是GQL ，关键在于你要理解一个计算机科学概念，也就是关注点分离（SoC）。一个设计良好的软件通常由多个层组成，每个层又分为多个模块。如果每个层和每个模块都有清晰严格的关注点分离，那么软件就容易理解，复杂度也更低。为什么会这样？如果你知道在哪里可以找到某个功能的实现代码，你很快就会知道该如何去阅读它的代码（很可能会跨多个代码库）。就像REST和GQL在API设计方面所提供的一致性一样，清晰的SoC提供了一种一致性的方式用于找到每个功能的实现。开发人员很少会在他们了解得很透彻的软件中引入bug 。