每个产品（每家银行）一个分支，分支和主干之间没有版本管理的关系，分支之间完全独立。
每个分支一个团队，在迭代中的需求和问题，选择性的通过主干的迭代升级实现支撑。
分支是基于主干的一个基线版本作为开发起点，不会跟进主干的基线版本迭代。分支可能会跟随主干的一些小版本的迭代。或者说，分支面临一些新需求，需要主干支撑，主干通过迭代到新的版本实现，然后分支跟随到该新版本。
这种方案的好处是分支选择的主干基线版本稳定，分支的基础就是稳定的。相反，如果分支跟随主干基线版本升级，则主干的每次升级，都需要每个分支做全面的回归测试。
这种方案的一个问题是，如果分支面临一个新需求，比如增加分布式缓存，如果分支选择的老的主干基线版本不支持，又无法选择新的主干基线版本，则分支可能无法实现该需求。分支选择的主干基线版本越老，面临的该类问题可能性越大。
第二个问题是维护成本的增加。随着分支线越多，面临的该类问题越多。这样在分支线和主干线上的维护成本会越来越大。
第三个问题是，主干的版本演进要做到向下兼容。
当分支面临新的需求，一种方案是在分支的版本上进行重构；另一种方案是基于最新的主干的基线版本进行重做。
SS层，微服务框架的组件层。包括redis，kafka，mybatis等等。
SSP层，各产品线的业务层，包括了业务层的各个微服务。
产品线比如银企通，T信等等。
银企通又可以再细分到各个银行，每个银行都是一个分支产品线。
在该层所有的微服务中，比如SSP-Bis-Bill，是各产品线通用的微服务。有的是各业务线通用的微服务，有的是各产品线通用的微服务。
SSP层的划分
把微服务按产品线划分，比如业务服务（和业务有关，组合封装其他服务），
把某个产品线通用的微服务划分出来，比如微服务（和业务有关，产品线内可以重用）
把各产品线通用的微服务划分出来，比如实体服务（和业务实体有关，在不同产品线内可重用）
还有和各业务流程无关，封装底层技术中心功能，可以重用，比如公共服务（通知、日志、安全等）
划分的好处是什么？
微服务的划分属于服务规划范畴。对微服务进行了梳理和识别，通过横向和纵向的划分，从产品线的维度（纵向），业务相关性和重用性的维度（横向）。
再通过生产环境的数据，比如调用和日志监控数据，获得微服务及微服务之间在各个维度方向上的数据，并生成全景的看板视图。
通过对生产运营数据的分析，或者对于一个新需求的分析，可以分析问题应该对应到哪个产品线（纵向），同时应该属于哪个层次（横向），是应该升级原有的微服务，还是新增微服务，还是需要把原有的微服务拆分。