昨天几个小伙伴和部门领导一起就产品的交付形态做了一番的讨论，当时对以下的三种形态进行了探讨
- 将代码进行大融合，合并成一个工程（即回归大单体）
- 研发依旧多个工程，交付时根据需要合并成一个
- 每个产品一个服务、公共服务独立一个、技术产品独立服务
当前我们按产品线分成了多个组，每个组都会按服务的方式进行拆分（当然粒度不会很细），同时在逻辑上这些都属于一个大产品的一个部分。但在交付时，一般都只是交付这个大产品的少数几个部分。
虽然只是交付了少数几个部分，但产品的服务自身，加上依赖的中间件等，其要部署的量也是很可观的。
所以，就有交付团队给公司的大领导反馈当前的微服务架构可能存在过度设计、交付过程部署复杂、资源投入过大等问题。于是部门便收到了一个待办，目的就是降低交付团队使用产品的复杂度。
对于上面的三种形态，当前实际情况最接近的是第三种，所以落地最容易的也就第三种。但要给领导汇报，这三种方案的优缺点和可能的成本都要说清楚，在大家的碰撞中，也出现了各种的看法。
那在整个合的过程中，都会遇到哪些困难呢
- 数据库，当前每个服务都有自己的数据库，在合并时可能会遇到以下问题
- 表名的冲突
- 表策略冲突（有的可能读写分离、有的可能分库分表）
- 单数据源/多数据源问题，如果将所有表放到一个库下，那数据库的压力问题就很严重；如果保持多数据源，那么改造成本会较大
- liqubase的配置，每个服务都使用了liqubase来自动化创建表格，所有每个服务都有master文件，合并后master文件如何应对
- 配置，这里的配置可分为配置文件和Spring的Bean配置
- 配置文件
- 配置项的冲突，例如数据源的配置，其配置项都是一样的
- 配置内容的冲突，例如相同的配置项，需要的配置值不同
- 有的用了配置中心，有的只用了配置文件
- Bean配置
- Bean的命名冲突
- Java 配置类中配置冲突，例如有的服务使用默认的Bean，有的对Bean进行了特定的配置，例如SpringLiquibase
- 方案或策略的不一致
- 调度方案，有的可能是Spring自带的，有的可能用了分布式调度
- 认证方式，有的可能用Spring Security，有的可能是其他框架，即便使用相同的框架，实现的方式可能也不同
- 权限控制，有的可能硬编码，有的通过Mybatis拦截器，有的通过对JDBC的代理来实现
- 响应结构，有的统一了响应的数据结构，有的没有，响应结构间还不一样(如字段名或类型)
- 异常处理，有的可能用了AOP，有的可能其他方案
- JSON序列化反序列化，例如对日期的格式要求，值为null序列化策略
- 工具类冲突
- 日期等各种工具类
- 中间件冲突
- 使用的版本冲突
- 要求的部署模式冲突（单节点、集群等）
- 特殊场景对中间件有特殊要求（性能、稳定、监控等）
合并后可能带来的问题
- 开发过程
- 代码编译，其过程会变得更长，出错的可能性更高(如各种依赖)
- 代码合并，过程更容易导致冲突
- 协作过程，并行协作的过程也会更容易出问题
- 调试过程
- 启动更慢
- 更容易阻断进程（别人的问题导致系统运行异常）
- 测试过程
- 更频繁的回归测试
- 压测瓶颈更易出现
- 运行过程
- 功能隔离困难，一个功能异常可能导致整个系统崩溃
- 资源隔离困难，不能更好的为核心功能提供更多资源
- 升级过程
- 升级风险增加，因为这是全量代码
当然，合并后给运维带来的好处也是明显的
- 部署更简单，因为部署的服务少了
- 问题排查更简单，因为调用链路短了
- 运维要求更低
这里又引出了关于“降低运维成本”的讨论，有的小伙伴认为应从产品自身角度来降低运维要求，主要从以下两点
- 支持一键部署
- 完善的监控手段，排查问题更简单些
更多的小伙伴认为这种方式并未降低运维成本，反而可能还增加了成本
- 一键部署可以方便完成部署，但对运维来讲这是一个黑合
- 完善的监控手段，需要的资源会更多
- 无论一件部署工具还是监控手段，本身也是一种新的复杂度
- 客户的实际情况是可能连IT部门都没
- 客户对系统建设的投入有限
上面的两种看法，其实是站在了两个角度，第一个更多是站在了技术工作者的角度来思考的，第二个更多是站在客户的角度来思考。最终我们的选择以客户为主。
虽然主基调最终落在了“第二种形态”和“第三种形态”上，但过程还在探索，结果还不好说~
这次的探讨还比较激烈，但总结后，我们应该认识到以下几点
- 软件是支撑业务活动的基础设施
- 先有公司的业务模式，才有支撑该模式的业务功能
- 软件的完善程度不是衡量其价值的根本标准
- 企业的业务广度和深度决定了软件的复杂度
- 企业的业务广度和深度决定了软件的成熟度
- 好的软件产品，也可以反向的推动业务模式的进化
所谓的过度设计，往往是因为只站在了研发人员的角度在思考产品，从而纯粹将产品的高性能、高可用、高可扩展等指标作为了衡量产品优差的标准，同时还总会将“最新的理念”和技术融合到产品中，但如果该产品不能符合客户的需求（包括资金、运维成本等），那么对客户来讲，这只是一个美好的花瓶。
所以好的产品是“刚好满足”用户需求的产品。
