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

我工作十余年，从负责一个模块，到负责一个产品，再到负责整个支付平台的架构设计，包括业务架构、产品架构到应用架构，再到技术架构，是一个从点到面逐渐转型的过程，同样是个“自相似”的现象。

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

通用的架构方法论

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

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

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

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

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

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

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

通用架构师能力模型

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

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

需求分析

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

程序设计

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

线上应急

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

技术攻关