架构设计怎么平衡当下和未来的业务发展？

最近团队在优化系统过程中遇到如下两个场景。

第一场景是现有交易系统越来越臃肿，既要满足交易系统自身功能和下游系统业务编排功能，又要对app多版本的支持，直接导致的问题是交易系统打包的版本需与app版本对应，也就是app对外有支持几个版本必须相应部署版本不同的交易系统，因交易系统部署的版本多，出现消息队列消费低版本交易系统的消息，解决这个问题需每个版本都要不同的topic名。

第二个场景是我们在设计数据系统过程中，对服务的粒度划分问题进行探讨，有人建议此次设计需要将统计功能和定时任务功能各自服务化，统计模块在没有大数据量场景下是否需要设计成服务化大家有不同的见解。这两个场景分别涉及到垂直划分的问题和水平拆分的问题，这两个问题是架构设计中最常见的问题。

下面是关于这两个问题设计原则的探讨。

关于垂直划分有如下原则：

业务变复杂，影响到系统的灵活性

特定技术要求，需要与业务解耦合

根据如上原则第一个场景对交易系统进行架构演进，第一次演进是从交易系统上游增加一个网关系统，原交易系统提供版本控制，安全验证和对外服务等功能移到网关系统，通过网关来解决版本控制，安全验证等特定技术问题，这次讨论中系统演进增加了一个服务编排系统，用于组合各个业务系统业务以降低交易系统复杂度和增强交易系统的灵活性、通过服务编排系统解决了交易系统多版本支持问题和下游业务系统编排问题。如图设计：

关于水平拆分原则如下：

增加业务的清晰度

如果业务规模小，可以通过包或者不同工程区分不同的业务模块，当业务规模达到一定规模才有必要将业务模块服务化，否则增加不必要的人力资源和硬件资源等。

单个系统无法满足性能要求

随着公司的发展，单个系统开始出现性能问题时，是对业务系统进行水平进行拆分服务化，对数据进行分库分表的时机，以适配业务规模的发展。

适配公司的组织架构

根据康威定律，设计系统的组织其产生的设计等同于组织的沟通结构，也就是说当架构设计不适配组织架构，设计的系统是反康威定律的，导致沟通成本高效率低等问题。当一个项目团队也就人开发人力少业务规模小的时候，只需要在代码结构保持业务的清晰度即可，没有必要服务化。

特定技术要求

这点要求与垂直划分的原则一致，比如定时调度任务、配置文件管理等等特定技术要求系统，需要以业务系统解耦。

根据如上四个原则，因数据业务场景简单和人力规模小的特点，数据系统的设计变得清晰化和简单化，把原有的规划统计模版和和任务模块进行简化，保留定时任务等特定技术模块，其他模块保持不变。如图设计：

架构的本质在于折中，折中不是中庸是得失和取舍的权衡，是抓住重点，把人力、技术和时间等资源用于最重要的事情。

-END-