【基础安全】堡垒机的自动化功能实践4
上一章节，介绍了用户申请流程与管理员处理工单流程的选型与设计。
这一章节，将结合实际情况（由于底层基础设施的差异，导致实现过程中会有差别），从以下三方面介绍架构调优。
01
—
框架
不知有没有读者在阅读上一章时，会想起使用一些成熟的框架来实现业务流程，比如celery。但同时会带来不少问题：
- 框架依赖于语言，比如celery须使用python，那么就不得不使用python语言编写其中某些模块；
- 存在学习成本，学习与掌握一个框架，需要考虑一定的成本；
- 可扩展性受限制，由于依赖了某个框架，则后期的扩展必须都要使用这个框架，提高了后期的维护成本。
总之，框架带来了便利，但也会形成依赖。适当的抛弃框架，不失为一种长久的方法。
02
—
原子性
首先看一个简单的流程：当消费者从exchange中消费信息，并调用相应的API，该API在创建相应资源后，必须要发送消息到下一个exchange。比如：bh-identity-consumer从bh.audit.pass中消费消息，然后调用API add-identity。API：add-identity在成功添加资源后，需要向exchange：bh.rule.ready发送消息。
该案例中的原子性，即成功添加资源与发送消息，要么同时成功，要么同时失败。
- 实现原子性：微服务下的最终一致性，可以通过更成熟的基础设施服务来保障。比如，当用户成功请求API后（在数据库中添加记录），有后台程序会解析数据库记录（比如监控binlog）。如果发现符合场景的记录，则调用响应的脚本，完成消息发送操作，但是这就要求公司必须拥有成熟的基础设施。如果使用公有云，也可以借鉴下AWS的成熟产品，DynamoDB Streams，提供了完整与成熟的解决方案。
基于公司现有的基础设施与业务场景，可能并不能满足上述要求，与此同时可以通过非原子性来实现或补充功能。
- 实现非原子性：在某些业务场景下，不一定需要强制保障该功能的原子性。比如成功添加资源，实际并没有发送消息到mq，而是通过为记录添加消息成功发送属性或者标志位实现。又比如用户请求了资源创建API，虽然创建成功，但并没有成功发送消息到mq，而是通过业务维护人员定期查看到有哪些记录没有成功发送消息，然后再次向mq发送消息实现。
03
—
无服务器
在整个流程图中，用户可以看到有很多consumer从mq中消费消息。consumer是一种时刻监听mq的后台程序，虽然能几乎实时消费消息，但是也带来了资源浪费。如果公司对成本控制比较严格，大家可以考虑使用成熟的方案，比如serverless，当有消息发送到mq中，mq将自动启动消费者（serverless）来消费消息。serverless支持不同的事件源，通过配合不同的事件源，也能很简单处理原子性的问题。因此，无论在资源的消耗，还是在架构的实现上，serverless都比传统方案具有更明显的优势。
上图是基于AWS产品与服务实现的架构方案。此方案做到了按照计算收费（而非资源），此外由于AWS提供了多种事件源，也能解决原子性的问题。
04
—
总结
在堡垒机申请的整个系列中，从需求讨论，方案探讨，核心问题的解决与架构调优四个方面，完整介绍了该功能的实现。然而堡垒机申请，只是公司诸多场景中的一个，但是它涉及模块比较多且实现相对复杂，对开发人员有一定的要求，同时需要对微服务架构有一定程度的理解与实践。不过，实现的方案很多，只有基于公司现有基础设施、快速解决现有问题，才是衡量实际解决方案价值的标准。
如果有更好的思路，不妨多多交流！