像架构师一样思考

开篇

作为一个软件开发从业者，常常会面对一个问题——如何匹配不断变化的需求和日新月异的技术变迁。这个问题常常会转变为两个极端的编程模式：面向客户编程和面向新技术编程。面向客户编程以敏捷和scrum为主流思量和工具，以用户需求为基础，讲究MVP（最小可行产品），不断进行冲刺和迭代而忽视系统的演进。无视技术债务的积累。而面向技术编程正好相反，过度重视技术的迭代而忽略最终用户的感受。

这个问题会导致产品和研发团队争执不休，最终把皮球推给架构师。这也是我希望开启这个系列的原因——如何像架构师一样思考以及解决问题——因为有太多的皮球到了我这里，我相信一定还有很多的研发人员以及架构师面临跟我一样多的皮球😂。作为像架构师思考系列的第一章节，也是本系列的第一个专题，我选择了"面向成本设计"这个主题，这也是每一个架构师需要第一时间思考的问题。

如何像架构师一样思考？在回答这个问题之前，我们先来看一看什么是架构师。技术达人？业务大咖？还是协调各个研发团队构建企业级应用？

以上全对！事实上，在一个企业，一般存在三种不同的架构师类型-企业架构师（Enterprise Architects），方案架构师（Solution Architect）以及功能架构师（Technical Architects，也叫Functional Architects）:

企业架构师（Enterprise Architects）- 关注企业IT战略和组织愿景的匹配，着眼企业整体IT架构的现状和演进以推动和辅助企业的商业愿景。举个栗子-人工智能、物联网或者区块链怎们能推动和巩固自己企业的行业竞争优势。
方案架构师（Solution Architect）- 是企业架构师和功能架构师的桥梁，关注如何将IT架构愿景落地到一个个业务单元，同时需要识别相关的干系人一同将架构方案落地。同企业架构一样需要很强的沟通能力以及技术广度。例如：自建IDC还是采用云原生，能够清楚知道每种方案的利弊以及对企业最行之有效的方案。
功能架构师（Technical Architects）- 关注架构落地的细节，需要极强的行业及技术深度以及组织各个团队从底向上一步一步构建切实有效、可演进的系统方案。例如：如果使用云原生构建一整套高可用的微服务，如果进行资源整合和全链路追踪以及错误处理。

这三种架构师的职责会有重叠，企业中也可能会有不同名字但是职责类似的岗位。可以看到，这三类架构师的定位是一个从高到低、从业务向技术的一个演进，每种架构师的技能树也不一样-企业架构师需要优秀的沟通能力，广阔的技术视野以及敏锐的商业嗅觉，功能架构师需要坚实的技术深度以及对资源、架构和未来发展的整合能力，而方案架构师则在这二者中间充当一个协调者的角色，各种技能需要兼备。

看到这里，有的同学可能会感到疑惑，想要成为一名架构师，应该从哪里入手，选择哪个方向呢？如果您仔细阅读以上三种架构师的描述，会发现他们都有一个共同的特点——需要优秀的沟通和协调能力。为什么需要沟通协调能力呢？这就要回到写本专题的原因了——架构师需要有很多品质，其中最基本的并不是对技术的精通或者对产品的了解（当然它们也很重要），而是"妥协"。您没看错，妥协是成为一个合格的架构师的必经之路。这个世界上并没有一个完美的架构，同样没有一个不能裁剪的需求。作为一个合格的架构师，需要知道什么时候要向需求妥协从而产生一些技术债务，什么时候需要向技术妥协而裁剪一些需求。

那么问题来了，"妥协"的依据是什么？答案是——成本。没错，这个似乎和软件工程文献里的种种过程域和输入输出格格不入。然而事实是，成本是软件开发中的通用语言（money is the ubiquitous language in software engineering）。不论是开发新功能还是重构，我们第一个需要考虑的都应该是成本。如果您熟悉软件开发中的资源三角——预算、时间以及范围——都与成本息息相关。成本决定了我们应该采用单体架构还是微服务，是应该用CQRS和Event Sourcing还是应该用关系模型，应该用mySql、noSQL还是newSQL，是应该自建还是买现有成熟的产品，等等一切技术决策都需要以成本为中心，这是作为一个软件企业的天然属性。

在"面向成本设计"这个专题中，我会介绍7种企业级软件设计模式以及其目前流行的变种。同时我还会对不同的企业级应用设计模式的开发和维护成本进行说明和比较。了解这7种设计模式之后，您会发现不管是现在流行的微服务、中台、CQRS都有其适用和不适用场景，即便同一种模式在不同的企业中也会有不同的适用场景。当我们把这7种模式了然于胸，那么不管是自建还是云原生，不管是面向数万用户的小型应用还是百亿级别的大型系统，不管是秒杀系统还是离线系统，我们都可以对其技术选型、未来发展以及成本控制了然于胸。

最后，期待您的关注！