如何识别架构方案是否合理

工程师成长到一个阶段之后就需要做架构设计了，当然这个架构背后的scope是不一样的，有的架构是围绕一个系统，有的是某个方向解决方案架构，更高级别的是整个部门的整体架构。

架构也分为技术架构和业务架构，技术架构可以认为是偏底层的解决方案，比如异地多活，多机房容灾。

业务架构是围绕于某一个领域的具体业务而来的。那在架构评审时如何判断架构方案是否合理，并提出建设性建议呢？

降低复杂度

首先需要你的解决方案不要过于复杂，复杂问题的解决方案往往是简单的，如果用一个简单的方法解决了一个复杂的问题，架构师的价值则更大。

一个方案如果足够简单，那么就值得依赖，过于复杂的方案就会显得过于刚性，缺少容错能力。

做架构方案首先要认清一个事实，架构是不断演进的。

唯一的不变是变化，相信很多同学刚接触软件开发时都听过这句话。

好的或者合理的架构不是一蹴而就的，是不断迭代而来的，没有人能完整预测整个项目的死亡，但是需要具备一定的前置视野，级别不同要求程度不同，比如半年、一年、三年，时间越久越抽象，越短越具体。

基于这个事实，架构合理性的一点要求就是【可扩展性】。

怎么理解呢？

在我理解，架构是元素+连接的组合。

元素越多越复杂、连接越多越复杂。不同环境之下不同元素本质也越来越复杂，综合起来，架构的复杂度就体现出来了。

解决架构复杂度就是解决元素复杂度和连接复杂度。

元素复杂度与连接复杂度的解决方案抽象看起来就是SOLID。连接解决的好，就决定了架构扩展性好。

连接宏观上包含了服务之间的连接、应用服务与存储服务的连接，数据中心的连接，这种连接的处理需要提供普世的通信协议；微观上包含了函数之间、类之间、模块之间，这种连接的处理需要SOLID。

领域思想

领域思想是非常好的复杂度解决方法论，他告诉我们从业务视角去看系统、看边界，这样可以更好的和业务迭代贴近，降低因为需求变得引起的架构大的调整，而且领域驱动中有很多其他的方法论对于架构治理非常重要，越大的组织、架构复杂度效果越好，比如上下文、边界、UL、事件风暴、用户地图、运营操作地图等。

分治思想

分久必合、合久必分。相信大家都听过，微服务也好、servicemesh也好、领域驱动也好、分布式服务也好，背后都是分治的思想。

为什么分？

分可以很好的把复杂问题分拆成一个个的简单问题，治理起来也就容易了。我们可以做横向拆分、纵向拆分、读写分离、一主多从、多主多从等。

怎么分更合理呢？

因为分了后续就需要考虑合，需要考虑治理成本，除此之外还包括多冗余一份数据，最终一致性问题等。

稳定性完备

如果说做架构是设计高楼大厦的话，那么再高大上的高楼，如果坍塌了啥也不是。所以，一定把底线守住。

需要关注于链路上服务的高可用，哪些是单点、哪些需要做容错。

好的架构方案需要体现出对于稳定性及性能的关注，比如上线初期是否存在问题？问题的比重什么样？需要采用怎样的降级逻辑与预案？

综合来说系统的可观测性就很重要，监控、打点、报警帮助我们开了上帝之眼，发现那些难以发现的问题。

另一种体现稳定性意识的是，每次需求变更都需要进行核心链路的测试、代码监测、压测等。