工程师成长到一个阶段之后就需要做架构设计了

降低复杂度

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

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

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

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

如何理解呢？

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

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

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

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

领域思想

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

分治思想

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

为什么分？

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

怎么分更合理呢？

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

稳定性完备

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

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

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

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

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