聊一聊架构
架构师一直是技术行业里炙手可热的职位，是无数开发者心中的目标。大家都希望成为架构师，架构工作给人的感觉是经验和技术的制高点，仿佛做架构就可以摆脱搬砖的命运，但事实真是如此吗？
每位技术人的职业路径都是相似的，从小工到专家，在入行初期一定会遇到团队中厉害的角色，往往就是架构师。有些同学认为架构就是一堆中间件的集合，能够用web、rpc、config以及message等框架攒一套微服务系统就是架构师，如果采用的技术越新潮，吼出来的性能指标越逆天，就代表架构师的水平越高。有些同学则认为架构就是为了服务业务，虽然业务是什么也不一定讲的明白，但是一定要有好的态度，尤其是要和产品运营搞好关系，当需求来了，能不顾死活的通过倒排和996按时把项目垒上线。虽然看似两个极端，但是这两类同学是普遍存在的，前者鄙视后者不懂技术，是业务的舔狗，后者批评前者不懂业务，是技术的囚徒。通过在不同团队或公司的历练，我们所遇到的架构师也有所不同，有些只看技术，有些则飘在空中，同样的职位，都是负责架构工作，那为什么有这么大的区别呢？想要理解区别，还是要先要搞清楚什么是架构。
架构到底是什么？有很多书籍和开放组织对架构做了深度探讨，但在充满现实主义氛围的今天，这些书籍和开放组织对于架构的定义并没有什么用，要么过时了，要么太技术框架化了，那架构就是一个虚无缥缈的东西吗？
既然每个人理解的架构都不一样，就代表在每个人心中架构解决问题的范畴是不一样的，这样看来架构就不是一个简单的一元概念，它应该是多元的，在笔者看来至少包含了三个方面：现在的情况、未来的变化以及社会性共识。这么一说，就显得架构更玄幻了，别慌，接下来笔者就从什么是架构、架构的目标以及如何做好架构来聊一聊，或许能够给你带来一个不一样的视角。
什么是架构？
架构的英文是architecture，以前读书时翻译资料，如果将它翻译为架构，就会被老板纠正为：体系结构，并被啰嗦一顿，结构代表软件系统是由元素以及元素间的关系组成，关系能够演绎系统如何处理外界的输入，同时体系代表系统整体风格是如何响应外部（需求）变化，架构这个词太单薄了，体系结构更为合适。
老板说的很对，不过架构这个词业界已经叫顺口了，很难去改，但是从体系结构的内涵可以看出架构包含了很多方面。
当前的情况
架构是当前情况的反应，它是由结构和行为组成的。结构就是组成系统的元素，它们可以是数据结构（或关系数据库表结构）以及接口，表示系统是如何定义和理解问题的。行为是系统向用户（或者外部系统）的承诺，它定义了输入和输出，在转换过程中，系统提供了价值。
结构和行为反应了系统现状，它们能够让开发者了解到系统的核心数据结构（或者领域模型）以及功能，更好的情况下，开发者通过深入了解结构和行为从而识别出系统的最大潜力和主要问题，这会为系统的演进带来有价值的指导。
对于现有系统的结构和行为有深入理解属于架构的范畴，架构不总是用来做新东西，对已有系统的认识和理解是架构最优先要解决的。
未来的变化
架构除了需要理解当前的情况，还需要拥有超越当下，应对未来变化的能力。架构基于现有系统的情况，识别出哪些是易变的，哪些是稳定的，以及哪些数据结构是最重要的。数据结构是否足够的抽象，其中抽象的部分是否能够有利于消除变化。
架构应该能够定义出系统在未来业务发展过程中可能出现变化的主要方向，并围绕这些方向建立起应对变化的原则，而任何在系统上的变更都应该符合这些原则。
建立系统应对未来变化的原则属于架构的范畴，这些原则在概念上包括但不限于：系统拆分、数据结构抽象、功能解耦、性能优化以及新技术选型与引入，在行动上体现为：完成业务需求的同时，能够按照计划逐步进行系统优化迭代。
社会性共识
架构不只是当前的软件系统和面向未来的原则，还包括在架构以及系统上工作的人。一个开发团队由Leader、资深开发、普通开发以及新人组成，他们就是一个社会性的组织，需要对架构达成共识。
如果新人进入团队，没有文档用于了解系统的主要结构和业务知识，只能从代码中逆向得到启发，这不是不能做，只是效率非常低下，而且对新人非常不友好。对于一个需求如何实现，普通开发和资深开发对于系统的改动点有非常大的出入，这不是观点的百花齐放，而是架构工作没有深入人心。
建设对系统理解的共识属于架构的范畴，架构不仅用来治理系统，也会用来治理维护系统的人，虽然维护系统的人由于角色的不同对于架构的理解有深浅，但是组织中的人对任何需求的理解以及设计输出都是具有一定包含性的，不是对立的。
架构的目标
架构由现在、未来和组织多元所构成，它的目标是减少变化带来的影响和成本，简单的说，就是系统能够以低成本的变动来满足需求。
如果是躺平的架构，不重视技术演进的架构，一定不能以低代价来满足变化，如果侥幸做到，这种守株待兔的成功也不会长久。
为了达到架构的目标，就需要架构时刻处于进化之中，只有不断向前演进和完善的架构，才是活的架构，也只有活的架构才能以低成本的变动高效的实现需求，甚至超预期的完成任务。
如何做好架构
架构的目标是减少变化带来的影响，而架构本身是当前的情况、未来的变化与社会性共识的体现，既然架构这么复杂，那该如何做好架构呢？有太多的著作来向你兜售如何做好架构，至于有没有效不得而知，但是就像架构的概念一样，它涉及了多个方面，很难一以贯之。因此，做好架构也没有一套包治百病的万精油打法，笔者认为做好架构需要注意以下几个方面。
识别与完善实体
架构的灵魂就是领域实体，在工作过程中需要时刻梳理、修改和完善领域实体。举个例子：假设构建一个商品系统，一开始可能只有一张简单的商品表，但是随着商品发布、审核以及编辑等操作出现，就需要从中提炼出商品草稿，商品操作记录等商品领域实体，其中一个商品有多个草稿和操作记录。如果后续有对商品系统提出更复杂的运营操作需求时，就可以基于商品操作记录来完善打磨。反之，如果不去在实体上下功夫，只是简单的在商品表中新增几个字段，那么随着几轮需求实现，商品系统架构就会慢慢劣化，最终只能依靠一个个看不下去的补丁活着。
对于领域实体的识别和完善需要时刻进行，就算需求没有产生，也需要不断的精化领域实体，去除多余的属性，比如：使用业务垂直表来降低核心数据结构的复杂度等。
沉淀下来的领域实体需要文档化，也会形成PPT向外部团队进行宣讲，这样对内能够统一思想，对外可以提升沟通效率。文档的沉淀不是一次性工作，要随着需求时刻进行。
采用好的模式
好的模式不只是在编码中引入设计模式来提升程序的扩展性，还包括运用一些分布式系统模式。举个例子：定义维护好商品系统的领域实体很重要，但是也需要梳理和抽象所有的商品领域事件，发布商品、修改商品、审核商品以及商品过期等等，使用领域事件以及分布式消息可以将商品核心系统与商品非核心功能实现解耦。比如：商品发布后会重新计算商品分数，如果将计算分数的逻辑放在发布商品代码的末尾，这倒没有什么问题，但是后续如果需要在商品修改后再重新计算分数，就需要改代码了。利用分布式消息以及商品领域事件就可以将商品发布和商品分数计算分离开，提升了商品系统的架构韧性。
除了异步消息，将名词接口转换为名词行为接口也会让架构变得清晰，通过实施接口隔离原则，能够提升内聚性以及单一职责性。举个例子：一个ProductService肯定跟不上ProductReadService、ProductAuditService和ProductUpdateService等名词行为接口的组合。
架构师需要掌握尽可能多的模式，并结合自己业务的特点，将模式运用到架构和系统中，解决问题，提升效率和质量。
注重代码审查
代码审查是建立社会性共识的绝佳场景，好团队都非常在意代码审查，不重视技术的团队只会在意项目的上线时间，不会关注实现过程。
对于Leader而言，如果不去关注实现过程，就无法做到有效的考核。代码审查是一个拉近架构师和一线开发同学的好机会，从如何编写健壮的代码，到如何理解架构，该怎样更好的完成工作，以及未来的架构是什么样的，在未来的某一天能够更好、更容易的完成工作。最重要的是，能够让被review的同学看到自己的工作在架构中的位置，知道自己也在为这座大厦添砖加瓦。
架构师要重视代码审查，如果架构师不写代码，就不能被称为架构师，因为他丧失了面对现实的体感，在代码审查中，除了修代码，还能修人。
持续优化技术债
技术债是架构腐化的表现形式，需要在组织中有效的发动成员识别技术债，管理技术债。举个例子：面对经常出现的线上问题，可能是由于系统交互不稳定导致，也有可能是产品做的不够完善，可以通过在后台系统（BOPS）中增加一个页面，提供给运营同学一个查询和修正问题的功能，而避免每次耗时且危险的数据订正。
有后台功能解放开发人员，组织也要对主动开发这些功能的同学加以奖励，并给予他们一些时间，同时还要跟进这些问题最终从产品层面去解决。
磨刀不误砍柴工，作为架构师和团队Leader要能够顶住压力，将团队工作时间的20%左右，用来持续偿还技术债，只有这样，团队才能越跑越快，而不是被债务拖累。
定期分享机制
团队内部（和外部）要定期进行分享，需要设立系统负责人，负责人不是在名义上挂一两个系统，而是要对系统足够了解，做好系统变更决策的一号负责人。系统负责人对当前系统架构，以及团队负责系统的整体架构有清晰的认识，能够将自己出色的设计与团队内部同学进行分享。分享的内容不仅仅是技术，也包括运行在系统上的业务数据（量级与趋势），系统负责人对于业务数据指标、增量和风险点有清楚的认识，可以选择在周会时对这些数据进行通晒。
一次分享活动，收获最大的不是听众，而是分享者。通过定期分享，不仅主动刺激分享者需要更全面的了解、剖析和解决问题，还锻炼了分享者的表述能力，以及发掘自身不足的机会。