分类品牌架构品牌的架构可以分为

转载

架构魔法之光 2023-10-17 21:25:01

文章标签 分类品牌架构架构师 API CSV 文章分类 架构后端开发

我们通常定义架构有几个层次，这包括业务架构、产品架构、应用架构和技术架构。

1.业务架构：描述一个企业围绕一个行业做了哪些业务，例如支付行业的收单、退款、出款、充转提等能力，这与公司对外和对内定义的产品无关。

2.产品架构：描述对外和对内定义的可销售的产品，例如微信的条码支付、扫码支付、公众号支付等。

3.应用架构：描述提供了哪些系统和服务来实现对外和对内的产品架构，从而支持公司的业务架构，例如微信内部的订单系统、支付系统、账务系统和对账系统等等。

4.技术架构：通常涉及采用什么的技术栈，以及各个技术栈之间如何分工和协作的，具体会细分为数据架构视图、服务化架构视图、缓存架构视图、消息架构视图、安全架构视图、性能架构师视图等等。

有了架构方法论，我们通常可以根据架构方法论的指导来设计和规划架构，而不再依赖于架构师本身的经验来设计架构，也不会把架构当做艺术来发挥，发挥好的时候设计出来的是好架构，发挥不好的时候设计出来的就是

坏架构。于是，按照行之有效的方法论来做架构的规划和设计，就可最大程度上保证架构设计的合理性，从而保证项目的成功。

通用架构师能力模型

有了架构方法论，我们通常在项目中或多或少的都会根据架构方法论来推进项目，使用架构方法论的这些人就是架构师，架构师会根据架构的种类和视

图具体分为不同的架构师，有业务架构师和技术架构师，技术架构师又分为数据架构师、应用架构师、性能架构师、安全架构师等等，那么这里我们给

出通用架构师的能力模型，这更偏向于应用架构师。

作为通用架构师应该有众多的能力，这涉及到方向、战略、策略、决策、影响力、规划等。

需求分析

一个通用架构师，首先要能够进行高效的需求分析，能够主动与客户沟通，理解客户需求，设计通用的业务流程，然后包装成产品，将落地的产品再输

出给客户，如果在业务流程上有创新就更加值得称赞了。

程序设计

大多数架构师都曾经是从工程师成长而来，因此，架构师应该具有程序设计的能力，当然这里的程序设计能力并不单单指的是编码的能力，更多的是将

业务流程转化成技术领域的语言，并带领一个团队将其落地实现。

线上应急

在互联网行业里，多数的系统是对 C 端用户的，用户请求量较大，对线上压力较大，线上系统粗线问题是家常便饭，这就需要一部分应急人员来解决

这些线上问题，一个通用的架构师必须具有应急的能力和经验，要了解应急的流程，紧急应急的目标，要以快速回复系统为己任，把公司的线上事故带

来的影响降低到最低。

技术攻关

在应急过程中或者项目实施过程中，一个最最要的环节是技术攻关，这个环节通常是需要架构师参与的，对于一些技术难点、应急过程中遇到的技术困

难，架构师要能发现并解决所负责领域的关键难题，通过技术手段来临时解决或者彻底解决，因此，架构师必须具有技术攻关的能力，例如，对于应急

过程中产生 OOM 错误，架构师要能分析内存模型，找到内存溢出的根本原因，并进行解决，《如何在生产环境排查 OutOfMemoryError（OOM）》一

文记录了笔者这几年处理的典型OOM的问题。

架构规划

能够使用架构方法论，带领业务团队做现状的架构梳理，以及未来几年的架构规划，能够结合组织结构和团队人员来定义部门的职责和界定部门之间的

职责边界。

架构师要对所负责的领域具有规划的能力，要制定规划的原则和目标，根据原则和目标来实施规划和落地规划，同时要引领所负责领域的发展，是所负

责领域发展的风向标。

风险控制

通用架构师一定要有风险控制的意识，无论对任何的设计方案要对风险具有嗅探的能力，如果是金融行业，把控资金底线是一项非常核心的要点，另

外，系统设计的技术安全性也非常值得重视。在做任何决策之前，一定要评估可能产生的任何风险，并能提出有效的防控风险的方案。

性能优化

互联网项目唯快而不破，性能是互联网项目的首要目标，因此对性能优化、性能容量评估的能力，是必须掌握的。可以参考《分布式服务架构：原理、

设计与实战》的第3章的内容。

掌控方向

架构师在项目开发过程中，一项重要的职责就是掌控项目的方向，一定不能让小伙伴们做事儿跑偏，我这几年在做设计评审的过程中，发现很多小伙伴

在解决无效的问题，或者不知道在解决什么问题，这是非常重要的一项职责。

我已经连续做了几年的技术序列升级的评审，发现一个共通的问题，就是大家做事儿的目的不明确，做一个项目不知道需求是啥，解决一个问题不知道到底问题是啥，说提高了性能，不知道原来性能哪里差，差到什么

程度，更有甚者不知道用什么来衡量性能，还有人上来堆砌一堆高大上的技术，比如有些人把高速存取的一共才几十 K的规则数据放在了 FTP，还有些人非要把交易数据放在 MQ 中，美其名曰用 MQ 保证一致性，追

问怎么保证的，回答说 MQ 保证 AP 模型，所以最近我和人讨论最多的就是做架构不要堆砌高大上的技术，要从问题本身出发，遵循目标、原则、方法、闭环的过程。

这里给大家举一个真实的案例，对账单通常是通过 CSV 格式对外提供的，此格式简介、高效、占用空间少、网络传输快，既适合人类阅读也适合系统对接。然而，有一天从前场传来了一个需求，要做 Excel 的对账

单，原因就是 CSV 格式有时候会产生乱码，产品经理接到这个需求就开始计划实施实现 Excel 格式的对账单。在评审方案的过程中，我首先想到的是要挖掘真实的需求，为什么有的用户看到 CVS 格式的对账单是乱码

的，根据经验和我对乱码的理解，如果设计的合理，使用正确的字符集打开 CSV，是绝对不会产生乱码的，于是经过询问，前场人员确认确实有些用户看到乱码，经过了解更多的信息，这些用户的系统默认使用的不

是 UTF-8 字符集，而是 GBK，因此，产生了乱码，了解到这个原因，那么解决这个问题最简单的办法就是，让所有的用户系统都通过 UTF-8 编码来打开文件，这完全可以通过写 CSV 文件的 BOM 头来解决。最终的解

决方案是，在没有上线之前，向导用户选择正确的 UTF-8 字符集打开文件，然后上线一个新版本，写 BOM 头让用户通过 UTF-8 来打开 CSV 文件来避免乱码。

这个案例里，架构师通过技术手段掌控了处理用户问题的方向，避免了通过增加 Excel 格式的对账文件来解决乱码的问题，因为那样的话就大材小用了，视图通过增加一个新功能来解决已有的 Bug，其实只是掩盖了之

前的一个 Bug 而已，并没有直接解决，因此做事情推进的方向性是非常重要的。

这里给出另外一个案例，在我评审的一个线上应急案例中，由于底层出现问题，导致上层系统出现了脏数据，为了解决这个问题有人提出了将数据的关键字段进行更新，避免数据被这个场景查询，这是一个典型的用一

个错误来掩盖另外一个错误的解决方案，哪里出现了问题我们就应该解决哪里，而不应该尝试用一种方法来掩盖错误，掩盖的方法可能会产生更大更严重的问题。这里，针对脏数据，我们应该果断的进行清理操作。

我推荐大家使用 “目标、原则、方法、产出” 的方法论来做事儿，做事儿前需要先确立目标和原则，然后评估各种方法，选择最合理的方法，做完事情要进行复盘，验证目标是否达成。关于此方法论请参考《技术人如

何修炼内功主题演讲》一文。

在设立目标的时候，要根据实际情况来设置合理的目标，不能过于偏激，也不能过于简单，过于偏激难以实现，过于简单又失去了斗志，就失去了进步的动力，因此，针对现实，要敢于设置有挑战的目标，并未目标而奋斗。

在设立目标的时候，要评估目标实现的价值，一个目标实现了产生100万的毛利和产生1万的毛利有本质的区别。

辩论能力

我已经连续做了几年的技术序列升级的评审，发现一个共通的问题，就是大家做事儿的目的不明确，做一个项目不知道需求是啥，解决一个问题不知道到底问题是啥，说提高了性能，不知道原来性能哪里差，差到什么程度，更有甚者不知道用什么来衡量性能，还有人上来堆砌一堆高大上的技术，比如有些人把高速存取的一共才几十 K的规则数据放在了 FTP，还有些人非要把交易数据放在 MQ 中，美其名曰用 MQ 保证一致性，追问怎么保证的，回答说 MQ 保证 AP 模型，所以最近我和人讨论最多的就是做架构不要堆砌高大上的技术，要从问题本身出发，遵循目标、原则、方法、闭环的过程。

这里给大家举一个真实的案例，对账单通常是通过 CSV 格式对外提供的，此格式简介、高效、占用空间少、网络传输快，既适合人类阅读也适合系统对接。然而，有一天从前场传来了一个需求，要做 Excel 的对账单，原因就是 CSV 格式有时候会产生乱码，产品经理接到这个需求就开始计划实施实现 Excel 格式的对账单。在评审方案的过程中，我首先想到的是要挖掘真实的需求，为什么有的用户看到 CVS 格式的对账单是乱码的，根据经验和我对乱码的理解，如果设计的合理，使用正确的字符集打开 CSV，是绝对不会产生乱码的，于是经过询问，前场人员确认确实有些用户看到乱码，经过了解更多的信息，这些用户的系统默认使用的不是 UTF-8 字符集，而是 GBK，因此，产生了乱码，了解到这个原因，那么解决这个问题最简单的办法就是，让所有的用户系统都通过 UTF-8 编码来打开文件，这完全可以通过写 CSV 文件的 BOM 头来解决。最终的解决方案是，在没有上线之前，向导用户选择正确的 UTF-8 字符集打开文件，然后上线一个新版本，写 BOM 头让用户通过 UTF-8 来打开 CSV 文件来避免乱码。

这个案例里，架构师通过技术手段掌控了处理用户问题的方向，避免了通过增加 Excel 格式的对账文件来解决乱码的问题，因为那样的话就大材小用了，视图通过增加一个新功能来解决已有的 Bug，其实只是掩盖了之前的一个 Bug 而已，并没有直接解决，因此做事情推进的方向性是非常重要的。

这里给出另外一个案例，在我评审的一个线上应急案例中，由于底层出现问题，导致上层系统出现了脏数据，为了解决这个问题有人提出了将数据的关键字段进行更新，避免数据被这个场景查询，这是一个典型的用一个错误来掩盖另外一个错误的解决方案，哪里出现了问题我们就应该解决哪里，而不应该尝试用一种方法来掩盖错误，掩盖的方法可能会产生更大更严重的问题。这里，针对脏数据，我们应该果断的进行清理操作。

我推荐大家使用“目标、原则、方法、产出”的方法论来做事儿，做事儿前需要先确立目标和原则，然后评估各种方法，选择最合理的方法，做完事情要进行复盘，验证目标是否达成。关于此方法论请参考《技术人如何修炼内功主题演讲》一文。

在设立目标的时候，要评估目标实现的价值，一个目标实现了产生100万的毛利和产生1万的毛利有本质的区别。

辩论能力

这里首先给大家举个真实的案例，我们都知道支付行业除了服务 C 端用户，还会服务商家，例如，一个商家要使用微信支付，首先需要在商家平台进行注册，其他的第三方支付公司亦是如此，注册的过程通常称为入网，入网一般会对商户提供一个 API 接口，用来进行自动化入网，入网后商户可以登录商户平台进行可界面操作对入网信息进行自助修改，但是有的商户嫌弃自助修改太麻烦，于是想要 API 接口进行批量修改入网信息，这样问题就来了，入网信息的批量修改 API 到底放在哪个系统来做，其中一个产品经理认为这个功能是商户平台提供的自助入网的功能不够强大，所以入网信息的批量修改 API 应该放置在商户平台上，稍微有些技术背景的人都会知道，商户平台是一个具有 B/C 架构的项目，不适合对外输出 API，对外输出的 API 应该放到自动入网 API 系统，如果真的把一个 API 接口做到了商户平台上，那会极大的影响系统的架构合理性，商户平台对外开放了 API 这不但不合理，还会有很多的安全问题，这个时候，我们不但要及时组织，更重要的是作为架构师，我们应该如何来说服别人。

架构师一定具有与人辩论的能力，多数的场景下，会有很多人质疑你的方案，质疑你的决策，这个时候并不是靠谁的声音大来压倒别人，而是通过一定

的方法来说服别人。

首先要持续积累影响力，要让小伙伴们信任你的方案开始，再逐渐的开始信任你的人，如果小伙伴对你的人认可，那么你的方案和决策就更容易被人接

受。

可以晓之以理、动之以情，说出之所以这类 API 接口不适合在商户平台上开发的原因，让产品经理知道它带来的架构不合理性，对外开放接口带来的

不安全性，以及由于 API 接口和 B/S 结构的技术栈不同而带来更多的开发成本。

有的时候，我们通过理论的叙述，很难说服别人，我们通常会找到一些经验或者历史数据来证明我们的思路是正确的。有的时候我们会通过类比来说明

问题。例如在上面的案例中，我们通常通过对比，来说服对方，因为自动化的入网是通过入网 API 系统来做的，那么修改入网信息也应该是由入网 API

系统来做，因为他们维护的是同一类的信息，只不过一个是信息的初始化，而另外一个是信息的修改，这就像我们生一个小孩，我们需要对小孩一直负

责到底一样。

影响力

架构师和工程师的一大不同就是架构师需要进行决策，要做决策必须让小伙伴们相信你的决策能力，凭什么小伙伴要让你评审方案？为什么小伙伴会听你的方案？这就需要架构师具有一定的影响力，这能够帮助你做决策、推动决策落地，因此，要不断的培养自己的影响力，要能够对负责领域的复杂问题的进行分析，分析后要判断事情轻重缓急，判断技术方案的优缺点，并与小伙伴们分享，让小伙伴在架构师的带领下学习和实施项目，营造和谐向上的技术氛围，也就是具有技术影响力和对团队的感召力。

架构师除了提高自身的影响力，还要能不断的识别核心技术人才，对有潜力的小伙伴进行培养，要定期的进行分享技术，营造技术分为，要对小伙伴进行培训，帮助小伙伴的提高。

决策能力

通用架构师要能参与高层的战略的讨论，并提出建设性的意见或者行之有效的策略，需要能够从利润、性价比、投产比的角度来考虑战略的制定和执行，要能参与和主导所负责的项目的策略和决策的制定，在需要做决策的时候，权衡利弊，果断给出最适合的方案。

然而，在很多场景下，直接说出你的想法和思路，是很难让人理解和接受的，因此，我们常常需要制定合理的规则，然后根据制定的规则，让小伙伴们根据规则自行推导出正确的方案。

这里，我们举例说明，架构师经常碰到需要对某个功能应该划分到哪个系统的问题，也就是职责边界的划分，处于某种内在的利益的考虑，有些是有应该负责这部分的功能的模块不想要，或者不应该负责这部分功能的模块却想要，这都是很可能的，不管是想要这个功能的模块的负责人还是不想要这个功能的模块负责人都会想出各种理由来支持他们的想法，这个时候，即使我们给出几种方案，并且明确列出几种方案的优缺点，我们还是要一一进行决策。在这种场景下，我们需要对我们考虑的利弊进行优先级排序，在这个时候，我们定义如下特点的优先级。

1.资金底线的保证

2.需求的急迫性

3.架构合理性

这样，我们就能很容易根据这个优先级来确定合理的方案，实际上，确立了这样的优先级，并且明确了每种方案的利弊，我们很容易就做出决策，甚至可以让小伙伴们自行说出决策的内容。

积极主动

多数工程师停留在执行层面，整体架构和模块设计都已经做好了，工程师按照设计做实现即可。而架构师则需要积极主动的承担更多的职责。

从点线面体看工程师到架构师的转型

根据行业共识，工程师向上发展的路径有两个，一个是走向管理，朝着技术总监和 CTO 发展，另外一个是朝着技术专家和首席架构师的方向发展，这是人为的把管理和架构的角色割裂开来看的，实际上架构师和技术管理的能力模型没有明显的界限，我所在的公司多数使用矩阵制度和项目制，一个事儿需要一个带头大哥来负责，带头大哥带领项目一起完成一个事情，这个带头大哥可能是一个技术总监，也可能是一个架构师，因此，我们在谈的通用架构师的角色是个广义的架构师，也就是能够带领大家完成一个独立项目的这样的一个角色，上面我们学习了通用的架构方法论和通用架构师能力模型，这里我们来看下工程师如何向通用架构师转型。