联系我们获取适合您需求的个性化 FinMV 报价。
贵公司的技术总监在计划推出金融平台时，必须选择项目架构选项。他有哪些架构选项可供选择，哪个更好？
一个新的投资平台只有一个团队、一次部署和一个数据库。在这个阶段，分布式系统的成本完全体现为额外开销：本可以用函数调用解决的地方却要经过网络调用，本可以用一次事务解决的地方却要依赖最终一致性，还要背负一支尚无人手承担的运维负担。
因此，默认实现是模块化的：入驻、发行、投资、支付、文件、服务与报表都存在于同一个可部署系统内部、彼此明确划界的边界之中。使其模块化的并非文件夹结构，而是每个模块都拥有自己的契约、自己的数据，并由自己的测试覆盖。
当存在具体依据时，一个模块才会被拆分为独立服务，而这些依据源自业务，而非架构潮流：
由于边界与契约早已存在，拆分服务只是一次有计划的操作，而不是一次重写。这正是这种做法的意义所在：这一选项始终保持开放，且成本始终低廉。
不需要阻塞用户的工作——结算对账、文件生成、服务商回调、报表生成——都通过队列处理。RabbitMQ 或 Kafka 这类消息代理只有在吞吐量或集成拓扑确有需要时才会引入,而不是默认使用。PostgreSQL 始终是数据的权威记录系统；Redis 仅用于确实需要低延迟缓存或协调的场景。
我们既不推销单体架构，也不推销微服务架构。二者都只是对尚未被提出的问题给出的答案。我们也不会为了让平台看起来更“正式”而去构建分布式系统——架构上的表演式设计运维成本高昂,交接也十分困难。
您的架构取决于您的业务规模、监管义务、集成需求以及负责运维的团队规模——并被设计为能够随着这些因素的变化而演进。
