通常，产品的初版被视为业务试错版本，其目标是迅速实现并包含核心功能，以尽早将产品交付市场，进行检验和问题收集，为后续的完善提供基础。我们也遵循这一方式，初版的实现重点放在了贷款申请的核心流程上。这样做的目的是为了快速推向市场，通过用户的反馈和市场的检验，识别和解决问题，并在后续版本中进行进一步的完善。
这里算是笔者的想象复原第一版的情况，主要是为了表述一个系统的架构演进。
系统架构
当前版本的架构相对简单，采用了单体架构。主要包括贷款管理、风险控制、第三方服务管理以及基础用户权限管理等核心功能，为贷款流程提供了必要的支持。服务端与终端之间通过 Rest API 进行统一的交互。这种简化的架构有助于快速实现核心功能，便于管理和维护，并能够有效支持产品的初版推向市场。在这一版本中，我们将关注于用户体验和市场反馈，以便在后续版本中更灵活地进行架构的升级和扩展。
由于是单体架构，部署上也很简单，启用多个功能相同的节点，使用Nginx或云厂商的SLB服务做负载均衡即可。
技术成果
由于使用了最简单的单体架构，又为试错版本，架构设计上只需要关注业务与代码的映射，一定灵活度的表结构设计即可，对高可用、性能、架构可扩展性等要求可暂不考虑。研发团队几个人，可以短期研发上线。
面临问题
在车贷系统项目中，初版的单体架构虽然看起来简单实用，特别适用于快速试错和POC阶段。然而，随着项目的不断推进和市场的反馈，一些问题逐渐浮出水面，而且随着业务目标和需求的变化，我们不得不面临一系列的挑战和改进：
- 目标调整： 为了实现年内覆盖全国100个地市，贷款额达到100亿的目标，需要对产品进行重要调整和升级。同时，吸收20000名销售顾问使用车贷APP，并逐渐形成独立生态，对系统的性能和扩展性提出更高要求。
- 需求变更： 贷款申请细节和风控逻辑需要频繁调整，而且要求技术团队能够快速响应这些变更。引入新的业务功能支持多业务线开展、接入三方辅助信贷功能、等级返佣活动、业务形态转化针对多个外部车商放款等，也对系统提出了新的需求。
- Bug修复： 项目中存在一些Bug，例如贷款申请时涉及的任务无法灵活组合，合同配置容易出错，定价方式不灵活可配，短信服务商和三要素验证供应商响应速度慢且不稳定，以及重复提交申请的问题等，需要及时修复。
- 架构限制： 单体架构在扩展性、复杂业务实现、性能、技术升级等方面逐渐暴露问题。开发效率低、不利于安全管理、技术升级困难等已经成为亟待解决的挑战。
- 团队协作： 随着项目版本迭代和团队成员的变动，规范性的约束逐渐失去作用，导致开发人员有意或无意地违反规范，影响了项目整体的质量和可维护性。
在这个过程中，我们需要在保持业务运转的同时，对系统进行迭代升级。然而，单体架构的一些固有问题使得这种迭代变得复杂：
- 扩展性差： 对于贷款流程的优化，需要整体部署，影响发布效率，使得版本更新变得困难。
- 功能难以拆分： 单体架构下，各功能点高度耦合，使得复杂业务的实现变得困难，而且很难杜绝开发人员擅自调用三方模块的内部方法。
笔者实践中发现随着项目版本的迭代，规范性的约束往往越来越发挥不了作用，当有“捷径”可走时总会有人带头无视规范，如不制止很快所有成员都会被同化，从而导致项目整体失控。
- 系统性能低下： 所有功能在同一个JVM中运行，容易因为某一接口问题导致系统整体不可用。
- 技术升级困难： 单体架构无法模块化地实现技术框架升级，使得项目难以跟随技术的快速发展。
- 开发效率低：1）达到一定代码量后编译、部署耗时高；2）每个成员都需要有完整的环境依赖，新人上手困难；3）多版本并行开发问题频现，对Git版本管理的要求高企
面对这些问题，团队需要仔细权衡和规划。新的业务目标和需求促使我们考虑架构的转变，但在服务化架构上线前，单体架构仍需进行一段时间的迭代。这一过程中，需要解决架构限制、提高团队协作效率，同时保障业务的持续稳定运行。在业务迅速发展的同时，团队必须思考未来的技术挑战，并在技术和业务之间取得平衡。
新项目架构是先单体再转微服务还是直接微服务？
在面临单体架构升级为微服务架构的决策时，需要进行全面的团队、业务和工期等多方面分析：
团队能力： 检查团队中是否有具备微服务架构经验的架构师和开发人员。如果团队对微服务不熟悉，可能需要从单体或传统SOA开始，逐步引入微服务的概念和实践。
服务积累： 考察是否有一定的服务积累，例如公共的登录鉴权、消息发送、服务注册、统一配置等。如果有现成的服务可用，对于工期较紧且需要快速迭代的项目，可能选择微服务会显得冒进，因为微服务的架构设计常常需要更多的时间和精力。
业务形态稳定性： 分析业务形态的稳定性，即业务是否在短期内会发生大的变更。微服务的划分与业务关系密切，业务模式的变更会影响服务划分，因此如果业务形态不够稳定，采用微服务可能需要更谨慎的考虑。
业务复杂度和规划： 考虑当下及中长期规划的业务复杂度。如果业务相对简单，而且未来一段时间内不会有大的变化，可能继续使用单体或传统SOA架构就足够了。
总的来说，决定单体架构是否升级为微服务架构需要综合考虑团队的技术储备、工期的压力、业务的稳定性以及业务的复杂度。这样的决策不仅关乎技术层面，还需要考虑团队的适应能力和业务的长远规划。
车贷最初选择上线单体架构进行试错，这是许多研发团队的常见策略。然而，这一演进方案的成功与否需要与管理层明确沟通：
- 产品技术的重构： 在选择单体架构的同时，必须明确向管理层传达产品技术一定要进行重构的信息。当前的架构虽然能够快速上线，但并不足以支撑业务的长期发展。重构是一项在业务层面看不到立即效果，但却是必须花费时间和精力进行的工作。
- 明确业务发展需求： 需要与管理层明确业务的发展需求，并说明单体架构在长期内可能面临的问题。如果这一点上不能形成共识，那么可能会出现在单体架构上修修补补的情况，使得系统越来越难以维护。
- 避免业务与技术脱节： 如果技术重构的必要性不能得到管理层的理解，开发团队可能会被业务所迫，不断进行临时性的修复，最终导致开发者士气低下，感觉毫无成就感。这可能最终导致项目的崩溃。
在这种情况下，团队需要强调技术和业务之间的紧密关系，以及长期来看技术重构对于项目的可持续性和成功发展的重要性。透明的沟通和明确的目标对于确保团队和管理层之间的共识是至关重要的。
架构设计在实践中确实不仅仅涉及技术和业务考量，更是与整个研发团队和管理团队的密切关系相关。
保护研发团队： 研发人员在架构设计时需要充分了解技术和业务的需求，同时也要保护自己的利益。这包括向管理层明确说明可能的风险以及应对这些风险的措施。透明的沟通可以确保研发团队的声音被听到，从而更好地维护团队的利益。
管理层的理解： 管理层需要理解架构设计中所反映的风险点，并深入了解软件研发的客观规律。明白适度的重构是为了产品的长远发展，而不是一味地跟随新技术或进行繁琐的变更。管理层需要在决策时权衡技术和业务之间的关系，以支持团队的决策。
满足多方期望： 好的架构设计不仅仅满足产品的预期，还要考虑研发人员的工作体验。一个具有良好设计的架构可以让研发人员更加开心、有成就感，并提高工作效率。同时，管理层也会看到这样的成果，并更容易认可和支持团队的决策。
在这个过程中，沟通和理解是关键。通过建立透明、开放的沟通渠道，团队和管理层可以更好地协同工作，共同推动项目的成功。
