三年前2015年进入一家国内知名的互金企业，随着公司业务的高速发展、系统架构也发生了天翻地覆的变化，本文只要介绍我司信贷系统如何从单体的系统架构演变为微服务分布式系统架构。15年初公司发展金融信贷业务，业务初创的特点：效率第一、快速上线、生存是第一要务，单体架构无疑是最佳选择。当时整个信贷系统工程包括十多个模块：预授信、欺诈规则、web端、支付、报表、定时任务、信审、催收、service、dao、tools等模块。业务快速发展 、需求繁多，单体架构的弊端显现：代码合并冲突问题、发布相互制约 效率低 易出现故障、代码庞大臃肿难以维护。
单体架构运行一年不到、我们进行了第一轮的服务化改造，技术框架选择了当时最火的spring boot ＋ spring cloud Netflix（eureka、hystrix、feign、Robbin），业务架构按照功能域进行拆分、单体服务拆分成：产品服务、风控服务、信审服务、清算服务、催收服务等；
一期服务化改造完成后不久、公司计划推出新的不同形态的信贷产品。这时候问题来了，以产品服务为例、是重启一个产品服务还是在原产品服务进行修改。如果重启一个产品服务、势必面临功能代码冗余情况，例如两个产品服务都有下单的逻辑；如果在之前产品服务里面进行修改，同样会面临之前单体服务的一些问题，随着更多的新产品推出、工程必然更加难以维护。
随着新产品的推出、我们进行了第二轮的微服务改造，这次技术框架选择了spring boot＋spring cloud ＋consul。以产品服务为例，我们抽象出信贷产品的核心领域、针对各个领域进行领域模型设计。产品服务核心领域包括：账户中心、用户信息中心、认证中心、订单中心、消息中心、协议中心、卡券中心，核心领域上面一层为各个产品的业务聚合层及与第三方交互的出口网关。
第二轮微服务改造半年后、业务高速发展、不断推出新产品以及外部合作产品，即使各个核心域服务抽象的足够合理、依然需要调整少量代码。为了提升整体的研发效率、针对信贷产品我们进行了一轮平台化改造，主要是将各个领域的核心流程及核心策略进行抽象、然后进行配置化，我理解这轮平台化改造既是组件化配置化改造。配置化改造完成后、研发效率大幅提升。
平台化改造后原以为整体系统架构能够满足一定时间内的业务发展了，改造完成半年后业务又有新动作、啪啪打脸，业务计划和第三方垂直领域的企业进行合作、推出针对特定人群的信贷产品（如与美团合作做小微商店贷）、输出我们的产品能力及风控能力、拓宽市场。与第三方合作、接口定义、开发联调等大大耗费时间，大量的时间花在了沟通上了。这时候建设信贷开放平台、提供标准的统一的接入方式成为重中之重。依托内部核心域的配置化能力，快速搭建开放平台、实效研发效率的提升。
整体信贷产品架构演进主要是拆单体（领域设计）、除冗余（抽象核心流程及组件）。谈谈自己对做好业务架构的一些想法，做好业务架构必须做到：1、必须精通业务、了解业务中短期发展； 2、不安于现状、适时重构；3、贴近业务、不为了技术而技术。如果不精通业务、无法做好领域设计更无法做好合理的抽象及前瞻的设计，我常和下面的开发强调、所谓的精通业务就是要比产品经理更加熟悉我们所负责的产品。不安于现状很好理解、这点不仅适用于整体架构同样适用于单体服务，安于现状必然会导致架构腐烂。贴近业务很很好理解、技术永远只是手段不是目的。
这里主要是简单介绍下我司业务架构演进的全流程，其实架构演进过程中还遇见了各种技术问题、往后再一一总结 文字化、加深自己的印象吧。