善变的架构

架构会有多善变？

上图是一个常见的App分层架构，之后随着业务发展，架构会如何变化呢？

再看微信在两个阶段结构图：

阶段1：

阶段2：

可以看到微信在阶段1架构类似于常见的App分层架构，但是随着业务不断膨胀，发展到阶段2某些模块发生了劣化。为什么会出现这种问题？架构随着业务不断发展，最上层业务模块横向进行扩展，某一个业务并不会劣化，同理，最底层的组件，也不会出现较大的劣化。随着平行的业务模块交互越来越多，依赖的业务功能按照普通做法只能下沉到中间模块，这时劣化就渐渐的开始。

明确了问题，那该如何解决？Gradle Module 只能一个模块依赖另一个模块，而不能再细化模块的依赖，那我们只能自定义依赖关系。在Module 里面划分小模块，分离Java Res Manifest 等资源，在property文件中定义该依赖哪些东西，在编译期检查依赖的合理性。如下图：

这样就可以细化模块之间的依赖范围，模块之间也可以相互依赖。依赖并保持克制。

良好的架构除了要保持代码和规范的良好性，还应该做到哪些事情？

单端单产品按业务复杂度大概分为三种规模，十人之下、三十人左右、百人团队。十人左右团队考虑的更多是怎么快速的迭代业务，架构考虑更多的是如何辅助业务发展。三十人团队考虑的更多的是怎么样保持业务的并行进展，架构考虑更多的是如何使各业务线耦合度更低、沟通更顺畅、业务性能可控，取决于架构的复用、解耦、稳定及监控能力，如果架构做不到上述几点，将会拖累业务的发展，甚至导致业务失控。百人团队考虑的更多是业务并行及可控性，架构考虑更多的会是产品整个生命周期的并行及支撑体系，例如，研发支撑：在线定位用户操作的链路，测试支撑：自动化测试脚本，运维支撑：稳定性分析、舆情监控，发布支撑：更精确的灰度验证、实时发布。

完整的产品生命周期包括，工程期、运行期、运维期，良好的架构应该有解决上述各个时期问题的能力。比如在工程编码期，编码规范及代码风格检查的工具。在工程编译期，检查模块之间依赖、生成辅助代码的能力。在运行期，监控App性能、压测模块的能力。在运维期，包大小预警、打包平台、在线提取用户异常业务日志、实时修复能力。

架构，善变。