邵千里，19 年软件行业从业经历，从程序员到架构师，再到 CTO、合伙人；2017 年走出“舒适区”，加入宝尊，担任企业核心运营部 IT 总监；2018 年主要负责宝尊核心系统的研发与运营相关工作。今年，邵千里被正式任命为宝尊技术与创新实验室首席架构师。

618 这场“硬仗”的指挥就是架构师

提到从 2017 年加入宝尊之后有哪些改变，邵千里调侃道，“最大的改变就是我开始有白头发了。”

2017-2018 年，邵千里“初来乍到”，作为宝尊核心应用部的负责人，承担整个大促支撑项目 IT 部分的项目总指挥，压力很大。每年的 618 和双 11，都是宝尊要打的“硬仗”，而作为总指挥，既要快速熟悉业务和架构，又要做好技术保障支撑，以应对超大业务量场景。2017 年，宝尊在内部启动了压测平台的研发设计工作，并于当年双 11 投入使用以支持生产环境的全链路压力测试。2018 年，整个宝尊系统在 2017 年的基础之上进行了优化，并对整个分布式应用治理体系进行完善，不仅做了架构升级，同时引入分布式消息中间件，进行服务拆分和引入 SEDA 架构体系以增强宝尊系统的吞吐能力，从而增加系统资源利用率，让系统支持更大的压力。

618将至，在这场全民狂欢的背后，所有电商行业都要为系统扩容规划和压力测试做足准备，同时需要提前规划所有系统的迭代计划以支持大促。

而这场“硬仗”的指挥就是架构师。

架构师不是吹出来的，是积累足够经验后的“水到渠成”

架构师的分类标准有很多，主要分为两种：一种是业务架构师，即企业架构师，偏向于企业组织架构设计以匹配整个企业的目标。这类架构师往往行业特性很明显，是某个行业里面真正的专家，主要负责组织流程优化等。企业架构师要像城市规划师思考如何建设智慧城市一样，为企业造起一座融合数字技术、实现业务重组的“大楼” 。

另一种是软件架构师，偏向于软件开发领域，主要的职责是根据问题域设计一个软件系统，针对问题域提出解决方案，比如设计系统架构、技术选型、攻克技术难题、解决技术盲区；还包括一些技术管理、技术指导、协助团队的技术能力提升等。软件架构师还会细分很多种，比如大数据架构师、网络架构师、系统架构师等，因为架构师不是全才，虽然需要有一定的技术广度，但一个架构师不能解决所有问题。术业有专攻，把架构师细分到具体技术领域，可以更有针对性地解决问题。

程序员到架构师并不是一个跳跃式的发展，而是一个渐进式的过程。邵千里提到，2000 年毕业之后，他首先进入了 Anderson Consulting，作为主程序员参与了一个 J2EE 技术的医疗电子商务项目的研发工作。不过很快就遇上了至今让很多人想起来仍心有余悸的互联网泡沫破裂的日子。

互联网泡沫破裂有多惨呢？举个例子，网易 2000 年 7 月上市，股价从 15.5 美元开始下跌，一直跌到了 0.48 美元，跌了 97%。市值从 4.7 亿美金，跌到了 2000 万美金。

“那段时间还挺郁闷的”，邵千里说，“但是我很清楚的是我对 JavaEE 技术是有热情的，所以我还不想放弃。”

后来，邵千里加入异联信息，从高级程序员、架构师、首席架构师，一直做到了 CTO。在 10 多年大量的项目实践中，积累了很多行业的技术、业务和管理经验。“我认为，经验是架构师最宝贵的财富。”

邵千里提到，“我不认为一个程序员在没有任何积累的情况下就可以胜任架构师。程序员到架构师中间的过渡因素很重要，第一是经验，第二是随时保持学习的状态。在工作过程中，有目的地培养个人能力，不断提升自己，随时做好接受更高难度、更复杂问题的准备。当你有能力解决更大的问题时，你就离架构师更进一步。”

架构设计思维和程序设计思维的差别很大，架构设计的关键是判断和取舍，程序设计的关键是逻辑和实现。最开始，程序员往往关注于解决一个小的问题；随着经验的积累，从一个小问题变成更复杂的问题，慢慢的可以带领一些程序员共同解决更大的问题，在更高层次上寻找分析和解决问题的方案，并开始关注项目的落地，这其实就已经开始由程序员向架构师身份的转变了。

架构师与程序员最大的区别不在于是否写代码。程序员——>架构师，中间有一个身份不可跳过，那就是优秀的程序员。做软件架构师，往往都是从程序员起步，如果没写过代码，根本谈不上做架构，因为你根本不知道怎么解决问题，也不会做问题分解。架构师不仅要对代码负责，更要对项目落地负责。

换句话说，架构师是能解决更大、更复杂问题的优秀程序员。

架构师要具备哪些素质和能力？

架构师要具备哪些素质和能力？邵千里提到 5 点：

业务理解能力

抽象能力

技术的全面性和广度

决策能力

写代码的能力

理解业务，即明确需求。业务理解能力是指架构师需要具备理解与表达能力，理解能力是指充分明确输入的需求，表达能力要求架构师与业务部门不断进行沟通与反馈，从而真正理解整个业务。

所谓抽象能力，就是发现事物之间相同点或隐含联系的能力。因为软件开发是一个高度复杂的智力活动，程序员经常需要面对、处理异常复杂的业务和逻辑，如果你不具备强大的抽象能力，无法把具体变成概念，进而驾驭概念进行思考，你就很难降低问题的复杂度。

程序员需要把视野放宽，整个架构的设计为了复用而存在的，你的架构要具有一定的重构性，这就要求你在解决问题时能抽象出共性的、最核心的部分，抽象层次越高，接口的语意就越模糊，适用的范围就越广。

技术的全面性与广度，这决定了架构师处理问题的效率。架构师要解决的不是某个点上的问题，而是面上的问题。所以架构师需要储备足够丰富的知识，从而可以解决很多上层问题。技术越全面，在做问题分解的时候，就能更快速地、一针见血地从问题域映射到解决域，从而形成技术方案。

从程序员做到架构师，需要培养决策能力。在技术领域，一个问题的提出，每个程序员会给出不同的解决方案，每个方案都有它的优劣，最终选择用谁的方案，需要有一个决策者，这个最后“拍板”的人就是架构师。往往那些有胆量做出决策而不只是提出观点和讨论的程序员，更有架构师的潜质。一些能力很强的程序员之所以做不了架构师，就在于他不懂选择，或者说缺少了一点胆识。胆识的关键在于“识”，其根源是过去大量的技术实践经验，这些经验给了程序员做出判断的底气，经过通盘考虑，最终确定哪个是更优的方案。技术选择能力是程序员要逐渐培养的自信。

写代码的能力是技术人安身立命的根本。代码很重要，因为这是程序员能力最直观的体现。程序员需要经常回看自己的代码，也要多看别人的代码。读源代码对于程序员而言是成长最快的手段，甚至比读一些技术书、学一些理论、背一些公式更有效。读代码的精髓，不是检查语法错误，而是揣摩这个代码是如何解决问题？为什么别人能想到这一点？如果换做是你来写，你会怎么写？有没有更好的方式？带着问题读代码，你就会有收获。如果你满足于复制、修改代码去解决问题，问题解决之后代码就“石沉大海”，可能你永远都会在低效重复地做同样的事。

懂得思考的程序员，一定是在思考——>沉淀——>总结——>应用——>优化代码的循环往复的过程中，当这个过程积累到一定程度之后，你就有能力去解决更大的问题。

架构师不是不写代码，而是他从一名普通程序员一步步做到架构师，中间积累了很多代码经验，很多基础性的问题已经不需要他自己来解决，而是交给团队里更合适的人。他要写的代码，是他之前很少写或者没有写过的，是要解决更高层面的问题。

在这次直播过程中，不断有网友提出问题，我们选择了一些有趣的话题，与大家分享：

精彩互动

架构师与项目经理，因为项目开发周期的问题，架构师不能调动团队人力怎么办？

邵千里：这是很典型的问题，因为架构师与项目经理的诉求和目标不一样，项目经理负责项目 ROI，需要赚钱，所以他关注的是用最少的成本，获得最高的效益。而架构师从整体系统架构的角度，对某些实现提出一些要求，认为在项目中要进行迭代，这会无形中增加成本，而这些成本是项目经理最头疼的。架构师和项目经理谁来让步？这取决于公司做这件事的目标是什么。如果公司只是做项目，那么架构师的整体架构设计就不需要有太多前瞻性或远期的考虑，而要关注平衡和成本。如果公司的目标是更长远的规划，那么在架构上付出的成本都是必需的，项目经理就要适当让步。

一个程序员想往架构师方向发展，需要做哪些准备？

邵千里：一个成熟的程序员会形成自己的技术路线，沿着技术路线发展会有两个选择：一个是某个技术领域的资深技术专家，另一个是解决问题的架构师，这是两个方向。如果要做架构师，第一，要多看理论知识，理论知识越扎实，对于后面学习其他技术领域的内容会越有帮助。所谓的快速学习，前提都是把基础打得很扎实。第二，要能写很厉害的代码。只有交付厉害的代码，让别人感受到你在代码里的设计和思考，别人才会把更大规模的问题交给你。

写代码有四重境界：“我的代码写完了。”——>“我的代码写好了。”——>“我的代码能用了。”——>“我的代码这么多年还在用。”

代码的最高级别就像一个艺术品，可以“流芳百世”。当你离开岗位，业内还有你的传说。这就要求代码不仅质量高，而且考虑全面，可维护性好，在写代码时做到充分考虑，选取最优算法。如果程序员把写代码视作一门艺术，写出来的代码就是一个艺术品。这样的境界，是每个程序员应该追求的最高目标。

为什么架构师与技术人员的沟通很有必要？

邵千里：首先我必须提一点，程序员不是不擅于表达，只是跟不懂技术的人很难交流而已。技术人之间的沟通是非常顺畅的。架构师与技术人员之所以要经常沟通，一是要保证技术方案能够落地，二是要得到技术人的反馈，并且去解答他的疑问，从而帮助他更好地执行技术方案。一个好的架构师要懂得培养技术人，允许他们提问，不要只是架构师部署任务，下面的人盲目执行。跟技术人交流，不仅帮助他们了解架构师的思路，帮助他们成长；同时技术人也会给架构师一些良性反馈，他们的建议有很多是可以让架构师醍醐灌顶的。归根结底，交流是让架构变得更好。

写在最后

不是每一个程序员都能成为架构师，这是开发界广为流传的一个论调。很多自称架构师的人在跟你讲一个架构时滔滔不绝，三句话不离高并发、高可用、大数据，但是稍微追问一下，就会发现很多基本概念的缺失。

架构师虽然听起来很高大上，但本质上仍然是工程师，是技术人，是程序员，还是要不停地学习。每一次设计架构方案，把复杂的需求抽象成简单的模型，从功能、性能、可用性、研发成本等方面规划如何构建一个系统，这是需要大量的实践经验积累的过程。

通往架构师的这条路，还很长。

创作场景

从 CTO 到首席架构师，跳出舒适区，“备战 618 的第一年我就多了几根白头发”