在第一篇文章中，我们讨论了从独立应用程序解决方案方法转向搜索连接器的必要性。在这篇文章中，我们将描述握手高层架构。我们选择转向微服务架构有几个原因：
- 较少的资源密集型
- 调度、组件重用和维护
- 更新和不断增长的技术景观
- 云和本地管理几乎是可以互换的
- 更容易管理用户(单点接触和管理多个线程)
- 部署和动态工作流的更大灵活性
- 更好地管理REST和SOAP协议
让各个部分相互交流
Handshake既可以作为自容器运行，也可以部署到现有的Wildfly服务器上。它使用Quartz、ActiveMQ Artemis、Mongo DB和Derby实现了一个可插入的组件框架。该包与源和目标接口、转换类(操作内容或元数据的可配置java类)和许可引擎捆绑在一起。所有的接口都可以扩展，但都具有生成用于处理的标准对象、连接到必要的系统以及在UI中显示所需的最基本特性。
前端Angular应用程序是单独部署的(通常在同一个域/防火墙中)。UI本身可以与任意数量的Wildfly服务器和处理器通信。这一选择最大化了我们扩展框架的能力。
额外的处理器可以在共享源硬件上运行，而不会影响性能。这里的最终目标是将任何内容流到搜索引擎。我们的解决方案需要足够灵活，能够在不影响性能的情况下与多种存储和通信协议进行交互。通常，我们为每个源服务器部署一个Wildfly运行时服务器，但这是灵活的，由客户机的体系结构定义。
应用程序可以打包并部署为本地管理的.war或dockerized容器(目前仅支持ECS, EKS已在路线图上)。
Microservice架构
两个连接器实例的例子:连接器1有许多队列，连接器2只有2个，直接向搜索引擎发送内容
Handshake通过JMS队列(ActiveMQ)读取和发送数据，以错开处理和跟踪内容。队列、作业和调度都是配置的实例。它们由一个总体处理器服务(每个处理器一个)动态地组合和管理。处理器调度Quartz作业，向UI发送统计数据和响应，并通过连接器实例路由内容。它还管理遍历检查点、散列和删除检查。
每个连接器实例都是一个单独的线程，不过支持多节点部署和实例的同步线程是在路线图上。连接器实例(和线程)的数量仅受所提供的硬件的限制。在以后的文章中，我们将讨论握手实例的性能需求和大小。
界面设计与开发
当我们为新的源(从其中提取内容的应用程序)或目标(向其发送内容的应用程序)进行设计时，我们确定连接协议(通常是REST API或数据库连接)，无论是PUSH还是pull，指定数据子集的方法，以及连接内容、元数据和权限的详细信息。然后，工作就变成了将这些协议映射到我们的API，以及对消费或传输的内容进行标准化所需的基本转换。
一旦对这些细节进行了编码和性能测试，它们就会被打包并添加到项目中，或者通过管理UI上传。它们可以作为连接器实例中的组件调用，用例要求使用多少次就可以使用多少次。
连接器实例的次要配置为Handshake提供了启动线程、读取和标准化内容以及将其写入JMS队列所需的一切。由于Handshake对对象进行了标准化，因此可以轻松地交换或修改源和目标。
接下来是什么
我们接下来的几篇文章将讨论我们产品的一些底层组件，导致我们使用它们的设计考虑因素，以及您可能考虑在自己的开发项目中使用相同组件的原因。
