15、基于微服务系统的架构解析

基于微服务系统的架构解析

1. 微服务迁移的其他特性及思考

在系统迁移至微服务架构时，目前介绍的迁移方法主要聚焦于基于领域进行微服务划分，以利于系统的长期维护与持续发展。然而，微服务还有诸多额外优势。在迁移时，明确推动迁移的优势所在至关重要，因为不同的动机可能会导致采用截然不同的策略。

例如，微服务能增强系统的健壮性和弹性，因为它对与其他服务的通信进行了相应处理。若遗留应用在这方面存在不足，或者已有的分布式架构需要在这些方面进行优化，那么可以定义合适的技术和架构方法，而不一定要将应用拆分为微服务。

以下是一些值得尝试和探索的内容：
- 研究剩余的企业集成模式：
- 这些模式在处理微服务时是否有实际应用价值？在何种场景下适用？
- 它们是否只能通过消息系统来实现？

2. 隐藏依赖问题

起初，软件以单体架构形式开发是合理且自然的。代码结构清晰，业务领域刚刚起步，所有部分基于共同基础，包含用户界面、业务逻辑和数据库。此时，代码重构简单，部署容易，开发人员也能理解整个代码。

但随着时间推移，代码量不断增加，变得难以理解。并非所有人都了解代码的所有部分，编译时间变长，单元测试和集成测试耗时久，让开发人员有时间去休息。在业务领域相对稳定且代码基础庞大的情况下，许多项目会考虑将功能分散到多个微服务中。

根据业务状况和业务/产品所有者的理解，会完成必要的任务，如分发源代码、创建持续交付管道和配置服务器。在此阶段，不会开发新功能，而这一不可忽视的努力仅基于未来其他团队能更快、更独立地创建功能的期望。虽然开发人员对此充满信心，但往往需要先说服其他利益相关者。

从原则上