本文为“技术琐话” 老司机李艳鹏创作，首发于“GitChat精品课”，获授权转载。

我工作十余年，从负责一个模块，到负责一个产品，再到负责整个支付平台的架构设计，包括业务架构、产品架构到应用架构，再到技术架构，是一个从点到面逐渐转型的过程，同样是个“自相似”的现象，我一开始写博客，再到出版《分布式服务架构：原理、设计与实战》，现在它的下册《可伸缩服务架构：框架与中间件》年后在京东首发，云时代架构系列书籍已经初具形态，也体现了从小到大的发展过程。

我很想把架构师成长过程总结成独立的系列书籍，苦于没有时间，于是，通过 Chat 把工程师向架构师转型的方方面面，和大家分享，帮助大家从开发向架构师转型要早作准备，记得早期的鸟儿有虫吃。

通用的架构方法论

有人说架构是一门艺术，架构的好坏靠的是架构师的经验和修行，但是近些年来，架构方法论如雨后春雨般的涌现，国际开源组织 Open Group 定义的 TOGAF 是其中一个行业标准的体系架构框架，它能被任何希望开发一个信息系统体系架构的组织自由使用，结合 TOGAF，我们通常定义架构有几个层次，这包括业务架构、产品架构、应用架构和技术架构。

业务架构：描述一个企业围绕一个行业做了哪些业务，例如支付行业的收单、退款、出款、充转提等能力，这与公司对外和对内定义的产品无关。
产品架构：描述对外和对内定义的可销售的产品，例如微信的条码支付、扫码支付、公众号支付等。
应用架构：描述提供了哪些系统和服务来实现对外和对内的产品架构，从而支持公司的业务架构，例如微信内部的订单系统、支付系统、账务系统和对账系统等等。
技术架构：通常涉及采用什么的技术栈，以及各个技术栈之间如何分工和协作的，具体会细分为数据架构视图、服务化架构视图、缓存架构视图、消息架构视图、安全架构视图、性能架构师视图等等。

有了架构方法论，我们通常可以根据架构方法论的指导来设计和规划架构，而不再依赖于架构师本身的经验来设计架构，也不会把架构当做艺术来发挥，发挥好的时候设计出来的是好架构，发挥不好的时候设计出来的就是坏架构。于是，按照行之有效的方法论来做架构的规划和设计，就可最大程度上保证架构设计的合理性，从而保证项目的成功。

对于一个项目我们需要从不同的侧面来描述项目的特质，对项目进行规划，让项目有条不紊的推动，我们通常依照架构方法论来设计架构，把架构分成不同的方面，这包括业务架构、产品架构、应用架构和技术架构，技术架构又可以细分成多个小的架构视图，这包括数据架构视图、服务化架构视图、缓存架构视图、消息架构视图、安全架构视图、性能架构师视图等，我们从这些不同的架构和架构视图来透析复杂的整体项目，架构方法论并不会保证我们100%的来透析完整的项目，而是要抓住项目的核心需求和特色需求，使用架构方法论的各个架构和视图来透析项目和规划项目，保证项目不跑偏，健康的进行下去。

通用架构师能力模型

有了架构方法论，我们通常在项目中或多或少的都会根据架构方法论来推进项目，使用架构方法论的这些人就是架构师，架构师会根据架构的种类和视图具体分为不同的架构师，有业务架构师和技术架构师，技术架构师又分为数据架构师、应用架构师、性能架构师、安全架构师等等，那么这里我们给出通用架构师的能力模型，这更偏向于应用架构师。

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

需求分析

一个通用架构师，首先要能够进行高效的需求分析，能够主动与客户沟通，理解客户需求，设计通用的业务流程，然后包装成产品，将落地的产品再输出给客户，如果在业务流程上有创新就更加值得称赞了。

程序设计

大多数架构师都曾经是从工程师成长而来，因此，架构师应该具有程序设计的能力，当然这里的程序设计能力并不单单指的是编码的能力，更多的是将业务流程转化成技术领域的语言，并带领一个团队将其落地实现。

线上应急

在互联网行业里，多数的系统是对 C 端用户的，用户请求量较大，对线上压力较大，线上系统粗线问题是家常便饭，这就需要一部分应急人员来解决这些线上问题，一个通用的架构师必须具有应急的能力和经验，要了解应急的流程，紧急应急的目标，要以快速回复系统为己任，把公司的线上事故带来的影响降低到最低。

技术攻关

在应急过程中或者项目实施过程中，一个最最要的环节是技术攻关，这个环节通常是需要架构师参与的，对于一些技术难点、应急过程中遇到的技术困难，架构师要能发现并解决所负责领域的关键难题，通过技术手段来临时解决或者彻底解决，因此，架构师必须具有技术攻关的能力，例如，对于应急过程中产生 OOM 错误，架构师要能分析内存模型，找到内存溢出的根本原因，并进行解决，《如何在生产环境排查 OutOfMemoryError（OOM）》（http://gitbook.cn/m/mazi/activity/59316fa64507e33120907ef2）一文记录了笔者这几年处理的典型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 而已，并没有直接解决，因此做事情推进的方向性是非常重要的。

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

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

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

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

辩论能力

这里首先给大家举个真实的案例，我们都知道支付行业除了服务 C 端用户，还会服务商家，例如，一个商家要使用微信支付，首先需要在商家平台进行注册，其他的第三方支付公司亦是如此，注册的过程通常称为入网，入网一般会对商户提供一个 API 接口，用来进行自动化入网。

入网后商户可以登录商户平台进行可界面操作对入网信息进行自助修改，但是有的商户嫌弃自助修改太麻烦，于是想要 API 接口进行批量修改入网信息，这样问题就来了，入网信息的批量修改 API 到底放在哪个系统来做，其中一个产品经理认为这个功能是商户平台提供的自助入网的功能不够强大，所以入网信息的批量修改 API 应该放置在商户平台上。

稍微有些技术背景的人都会知道，商户平台是一个具有 B/C 架构的项目，不适合对外输出 API，对外输出的 API 应该放到自动入网 API 系统，如果真的把一个 API 接口做到了商户平台上，那会极大的影响系统的架构合理性，商户平台对外开放了 API 这不但不合理，还会有很多的安全问题，这个时候，我们不但要及时组织，更重要的是作为架构师，我们应该如何来说服别人。

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

首先要持续积累影响力，要让小伙伴们信任你的方案开始，再逐渐的开始信任你的人，如果小伙伴对你的人认可，那么你的方案和决策就更容易被人接受。
可以晓之以理、动之以情，说出之所以这类 API 接口不适合在商户平台上开发的原因，让产品经理知道它带来的架构不合理性，对外开放接口带来的不安全性，以及由于 API 接口和 B/S 结构的技术栈不同而带来更多的开发成本。
有的时候，我们通过理论的叙述，很难说服别人，我们通常会找到一些经验或者历史数据来证明我们的思路是正确的。有的时候我们会通过类比来说明问题。例如在上面的案例中，我们通常通过对比，来说服对方，因为自动化的入网是通过入网 API 系统来做的，那么修改入网信息也应该是由入网 API 系统来做，因为他们维护的是同一类的信息，只不过一个是信息的初始化，而另外一个是信息的修改，这就像我们生一个小孩，我们需要对小孩一直负责到底一样。

影响力

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

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

决策能力

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

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

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

资金底线的保证
需求的急迫性
架构合理性

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

积极主动

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

下面给出几个反例，这些反例都是我评审过的技术序列升级过程中工程师常见的一些问题。

有的小伙伴平时接需求的时候，会显得很不乐观，面对需求的第一反应就是这个需求不应该我做，或者这个需求我做不了，并且会给出很多理由来支持做不了或者不该他做，这也实现不了，那也实现不了，有的时候还会摆出一些看似“合理”的技术名词来证明不可行，我就遇到一些小伙伴做了个批量查询功能，查询的内容是进行内存模式匹配，平均响应时间在10S以上，小伙伴陈述批量查询性能就是要低于单量查询，了解详细信息后，批量查询一次最多30条，每一条都是在做内存匹配，每个匹配都是纳秒级别的，为什么那么慢呢？详细追问是内存匹配的数据存储在 FTP 中导致，这是一种不严谨的行为，也是一种推诿行为，会给人以不好的印象，面对需求我们应该积极主动的承接。
在做商户平台的过程中，商户平台需要查询多个服务化系统的数据，小伙伴要求各个业务系统必须提供接口，或者构建统一查询系统才能提供商户查询功能，拒绝直接插数据库，从设计上可以理解直接查数据库不是最好的模式，但是基于现状的资源情况，这是最快速的方案。
有很多小伙伴对应急流程不关心，没有表现出对项目的主人翁的精神。

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

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

因此，我们在谈的通用架构师的角色是个广义的架构师，也就是能够带领大家完成一个独立项目的这样的一个角色，上面我们学习了通用的架构方法论和通用架构师能力模型，这里我们来看下工程师如何向通用架构师转型。

对于技术人员在职位上的晋升，我们通常通过点线面体来类比，这也是从工程师到架构师的晋级过程。

点：能够独立负责一个模块的开发。
线：能够根据设计，同时负责一个项目中多个模块的开发，甚至独立负责一个项目的开发。
面：在所在领域内，可以负责一个产品的整个研发过程，并对业务和技术要有前瞻性。
体：能够负责一个产品线的研发过程，并且能够开拓某个行业。

1-2所描述的能力模型比较符合工程师，而3-4描述的是架构师的能力模型。因此，为了获得3-4描述的架构师的能力，我们需要积极主动的去按照上面架构师能力模型进行休养，提前做好转型的准备。

对于3-4所描述的架构能力，我们通常通过深度、广度和高度上来衡量。

广度：要有全栈的技术知识，针对所在领域的技术要有全面的了解，能够评估各种技术的优缺点，要能根据优缺点来做技术选型的决策。
深度：要针对所在领域的核心技术有一定的造诣，阅读过源码，针对产生的 Bug 要有能够迅速定位的能力，或者曾经贡献过核心代码。
高度：能够理解业务的本质，能够识别业务的风险，并做出合理的应对，对业务和技术都要具有前瞻性。要理解业务的本质，对业务的特殊性有所把控，要能抽象事务也要能具象事务。要能用技术服务业务，或者推动技术的更新换代，或者推动业务创新，从而直接产生价值。

各个公司对工程师和架构师两个角色的定义不同，我也经常被 HR 美眉问到工程师和架构师到底有什么区别，一般公司都要求工程师具有需求分析和程序设计的能力，而架构规划的能力是架构师特有的，因此工程师要向架构师转型，一定要学会做架构的规划，未雨绸缪，要能够识别出现状架构中的痛点，提供有效的解决方案，规划将来的架构解决现状的痛点。

另外，对于线上应急和技术攻关，架构师并不一定需要亲自动手去做，但是在应急和攻关的过程中，架构师应该是要把控方向的，不要让大家跑偏，要严格把控应急和攻关的目标。

对于风险控制和保障性能的能力，无非是一个工程师向架构师转型的必备知识，作为一个架构师要实施把控项目的风险，要实时保证项目的性能能够满足用户对项目的性能需求。

作为一个工程师，通常是要理解需求，理解架构设计方案，可以自行写出模块的设计方案，并且根据架构设计和模块设计来实现项目模块，很少要与人研讨方案的优略，方案的选型，但是作为架构师这些能力都是要具备的，架构师经常要与人讨论方案，挖掘方案的优缺点，最后选择最合理的方案，因此要想从一个工程师转变成架构师，必须要培养辩论能力。

掌控方向是一个架构师独有的必须具备的能力，工程师在接受任务、完成任务的同时，需要多思考为什么我们要这样做，甚至为什么我们要做这件事情，做这件事情的价值是什么，不做有什么样的损失，要试图掌控事情的方向，才能更早的向架构师转型。

正确理解架构合理性的地位

我在做架构规划和把关架构评审的几年里，充分理解了架构合理性的定位，通常来说架构合理性保证的是至少未来3年后的业务和技术方向的正确性，然而做现在的事儿或者唯满足目前的目标为中心，或者完全以目标和盈利为导向的场景下，经常会导致急功近利，建设出来的是空中花园。

即使有一定的进步，也不会有质的飞跃，然而，如果以过程为导向，保证了整体方向的正确性，通常能够对业务或者技术打下坚实的基础，待量变积累到一定程度，会导致质的飞跃，这就是架构合理性的实际意义。

由于架构合理性的特殊定位，通常我将架构师团队比喻成发改委，发改委综合研究拟订经济和社会发展政策，进行总量平衡，指导总体经济体制改革的宏观调控部门，而架构师团队保证组织前进的方向的正确性，总体调控业务和技术架构的方向性，有时我还会将架构师团队比喻成政协，起着业务和技术方向的监督作用，以至于业务和技术的方向不会跑偏。

我们在实际的架构规划和实施的过程中，根据架构合理性的定位，我们通常认为架构合理性的任务是重要不紧急的事情，在金融的行业里，我们通常这样给任务做如下的紧急程度的排序。

资金底线的保证
需求的急迫性
架构合理性

我们看到架构合理性并不是优先级最高的考虑要素，但是是最重要的事儿，所以在短期的范围内，面对资金底线和需求的急迫性等，架构合理性是可以妥协的，长期情况下是不能有任何妥协的。

通用架构师如何修炼内功

作为互联网的通用架构师，是有别于某一个领域的技术专家，通用架构师不是专业与数据库运维的 DBA，也不是专业与安全的安全专家，也不是专业的性能测试专家，因此，对于那些专业的 DBA 工具、安全测试工具、性能测试工具可能都不会特别熟悉，但是，他们应该了解其原理，有了相关的问题，应该能够提供方法和方法论，组织相关的人员进行排查，因此，通用架构师需要修炼的是技术内功。

请参考 Chat 《技术人如何修炼内功》（http://gitbook.cn/gitchat/activity/598c68e55f3a7f37cb8aa253）。

通用架构师的社交软技能

权衡和博弈

架构师在多个相似的方案中如何应对各种博弈？又如何权衡利弊呢？我们需要先制定原则和规则，对利弊定义优先级，例如前面多次说道，在金融的行业里，我们通常对需求做如下的优先级的排序。

资金底线的保证
需求的急迫性
架构合理性

根据这些原则，我们对多个方案进行权衡利弊，答案自然就清晰了。

抓住要点

做事情要定要抓住要点，古语有釜底抽薪，擒贼先擒王，打蛇打七寸，都是一个道理，就是做事儿要做最正确的事儿，要识别现在的痛点，针对痛点给予致命的一击，一招解决问题。

前面关于为对账系统提供 Excel 文件做对账的案例也说明了这一点，我们要抓住用户真实的需求，直接解决用户的痛点，而不是用一个新需求来掩盖之前的问题。

社交软技能

虽然作为架构师，并不应该用技术总监一类的管理人员的要求来衡量，但是，我们为了达成一个目标，或者完成一个项目，我们需要发动多个小伙伴，需要与多个部门沟通，需要与领导沟通和讨价还价，因此，架构师要有基本的社交软能力。

这里我举几个例子，都是架构师应该具备的日常社交能力。

如果你定了会议室，你的领导要占用，那么无论你的会议有多重要，你一定要把会议室让给领导，因为领导的事儿远比你的事儿更重要，甚至领导开会可能是在为你解决问题。
小伙伴们再加班，领导过来视察，一定要拍照并发到朋友圈，这时你可能说这是拍马屁，错，这是在营造良好的氛围。

强力推动

有些事情做着做着就没了思路，没法继续推动，要不就是因为没人，要不就是因为没有方案，这个时候教给大家一个万能的解法，没人的时候先做方案，没方案的时候先安排人，在探讨方案的过程中可能会发现事情越来越清晰，也越来越简单，会增加小伙伴们的自信心，慢慢的问题可能就迎刃而解，在探讨的过程中要见缝插针，只要有一丝希望的思路都要继续讨论或者评估。

深入思考

要多观察，最好能够扩大参照系，站在较高的层次向下看可能会有惊人的收获，或者跳出圈子，在圈外来看圈内，或者站在别人的角度上看自己，这样会得到更多的客观的信息，有了足够的信息，要善于谋划，以客观信息为基础，制定合理有效的方案，才能解决问题。

这里给出几个深入思考的例子。

曾经由于 Fastjson 的安全漏洞问题，需要全面升级 Fastjson 的版本，仔细思考，如果部署一套网页应用防火墙（WAF）是不是可以解决一部分的问题，至少可以临时堵住很多安全漏洞，因此碰到一个问题，我们不能只站在自己的角度来看待问题，要扩大参照系来看问题，问题可能就迎刃而解。
要开发某个收入计算的批处理服务，收入计算依赖关系模型比较大，并且动态更新，小伙伴把整个关系模型维护在批处理机器的内存中，通过消息队列接受更新并且维护最新的内存模型，第二个月的第1天计算上一个月的收入情况，这是一个未经过思考的方案，场景是典型的批处理方案，但是使用了消息队列和节点内存维护实时的关系模型，浪费资源不说，稳定性还差，机器重启等都会导致模型的重新加载等等，对这类方案一定要深入思考，找到问题的本质，解决问题的痛点，而不是随意的堆砌高大上的技术。
把大约几 M 大小的匹配规则放到了 FTP，并使用 ZK 通知更新，为了使用技术而使用技术。
某个公司评估的方案，从私有云同步数据到公有云，要使用 Sqoop，Sqoop其实只是一个数据提取工具，并不是一个公网数据同步工具，方案没有经过详细思考。切记，不要为了使用技术而使用技术。

管理模式

架构师要理解和适应各种管理的方法，通常有传统的多层企业管理、扁平化的企业管理、矩阵式管理，一般情况下，扁平化管理的效率较高，沟通成本较低，适合初创企业，在这种管理模式下，架构师也比较容易发挥其价值。但是在多层的企业管理和矩阵式管理中，由于层次较多，沟通成本增加，一项事情从上面传达到下面要经历多个中层领导，中层领导需要一层一层往下传达。

传达过程其实也是一种成本，对于每个任务和项目需要沟通确认达成一致，才能保证项目传达的方向的正确性，由于层次多了，沟通成本增加，再由于中层领导区分战略思维，或者有战略思维没有落地经验，就会导致底层的人有可能没有完全获得上层人交给的任务，在下面就有可能“憋死了”，这些都是管理上的通病，架构师必须理解所处的环境，已经产生的问题，针对这些问题来提供合理有效的解决方案，毕竟组织架构也属于架构的一部分。

创作场景

从点线面体谈开发到架构师的转型