[微服务设计]4_集成

欢迎来到啾啾的博客🐱。
记录学习点滴。分享工作思考和实用技巧，偶尔也分享一些杂谈💬。
有很多很多不足的地方，欢迎评论交流，感谢您的阅读和评论😄。

1 引言

如果你已经开始编程15分钟，那么你一定会需要了解集成。

集成，服务与服务之间的合作方式。如果对通信有了解，其实“集成”和“通信”有类似的地方，至少都面临有三个问题：“数据传输”、“数据表达”、“定位”。

以《微服务设计》为大纲，包含水平有限的主观看法，欢迎讨论交流。

2 寻找理想的集成技术

2.1 怎样才算是理想集成？

服务之间通信方式选择非常多，同步、异步，不同传输方式、内容、格式等等…
服务之间，什么样的集成技术才是理想的，好的集成技术呢？

• 没有破坏性修改的
  重要的事情说三遍，解耦、解耦、还是解耦。
  我们需要保证集成的内容其修改不会影响我们的代码，做到无侵入式集成是最好的。

• API是技术无关性
  变化总是无穷的。以不变应万变的方式就是两者之间的联系是没有技术限制的。
  比如gRPC的接口语言定义语言IDL的表达，一个接口不管语言怎么变化，其提供给别的服务使用时都需要定位，需要使用方法名称、参数类型、返回类型来表达自己的“方法签名”。

• 服务易于消费的
  理想情况下，服务可以使用任何技术来消费。
  一般来说这种兼容是通过通用第三方来实现的，比如HTTP。

• 隐藏内部实现细节
  集成时不要与细节绑定，也不要为被集成的服务的细节做设定。
  这样耦合会很高，比如集成上游接口，针对其数据结构细节做了对应调整，可能性能能稍微好上一点，但是代码可维护性差的相当多，负责度也提升了，属于舍本逐末。

2.2 怎么集成？

现在主流的通信方式的集成方式都挺好的。要注意团队内部有时候为了省事的奇葩集成。
短期内省事，长期看遭罪。

• 为集成创建接口
  我们常见的各大厂商提供的API接口就是很好的集成提供。
  通过接口，只需要管理入参、返回就可以了。不需要注重内部实现，破坏性修改少。

• 共享数据库
  使用数据库，提供结构化或约定格式的数据与文件，使用数据进行交流。

集成和通信一样，操作都可以分类为同步、异步。
不同协作方式适应不同场景与问题。

当我们需要集成的服务变多时，我们需要面临一个协作调度的问题。
怎么让集成的多个服务不互相干扰？

• 指挥式
  创建一个服务作为大脑，统一指挥多个集成服务。
  

• 编排式
  这是一种去中心化，没有协调者的方式。服务之间通过事件驱动协作。

这两种方式都可以达成目的。复杂度、耦合性、性能权衡不相同。

3 集成注意事项

3.1 管理版本

如果一个客户端能够仅仅通过查看服务的版本号，就知道它是否能够与之进行集成，那就太棒了。
我们需要管理我们所集成的服务的版本，这有助于我们最小化兼容更改。

3.2 与第三方集成

与第三方集成的问题是：我们无法控制第三方。
比如不能预留资源，不能强制幂等。

此时我们能做的是尽量控制自己能控制的部分。
能控制哪些相关的呢？

• 定制化扩展
  为我们服务的未来计，我们集成第三方时需要警惕第三方的扩展。
  链条上方的扩展很容易影响到下方。所以，比较好的做法是封装成自己能控制的样子。
  比如使用适配器模式来隔离变化，控制逻辑。