总结一些技术架构设计的经验和认识、想法，供以后做架构设计时参考。
一、商业公司和大学的技术升级过程
技术的前进有两个途径，一个是业务（应用）的需求，另一个是理论研究。前者的生存发展环境是商业公司，后者一般在大学，或者商业公司公司的研究部门。
1. 公司创业阶段的技术升级过程
创业是寻找、定位、把握一个商业机会的过程。创业者一开始只有一个初浅的想法，需要通过产品落地、消费验证、利润产生等几个大的环节来最终发展起来。期间，尤其是初期，具体的产品功能和业务细节通常经历大量的快速的试错，来验证从产品到销售的各环节。
这个阶段，开发团队尽可能适应市场经营、运营团队的短平快的改进，产品只要有个大概的样子，基本能看能用，可以实现业务，可以供市场团队去验证，就可以。开发团队从功能和界面与市场经营团队、运营团队一起设计（甚至开发团队独自设计），然后尽可能的快速实现出来几个版本，每个版本的生命周期可能只有几周甚至几天，之后可能功能和界面彻底推翻，所以这个阶段快速出活是主要的，架构方面尽可能简化，刚刚够用就好，有时候甚至是够看就好。
2. 成熟公司的创新部门的技术升级过程
通常的内部创业。一个业务已经成熟的公司，经营者希望围绕核心产品，新建部门开展更多的产品与经营、运营的尝试。这个情况，开发团队遇到的问题与一般创业公司基本类似。虽然整个公司内部可以提供（基于核心产品的）成熟的技术框架及开发团队，但由于是新业务创新，所以有技术研究储备的开发团队最好重新迭代开发，实现功能与界面。只基于已有的技术架构，做业务创新，对业务的创新幅度有限。
3. 成熟公司的核心产品的技术小升级过程
这是一个活得比较健康的产品的典型行为。持续收集产品应用中来自技术、销售、运营等方面的新能力新需求，不断的小幅度改进产品，小幅度测试、发布、反馈修改，逐步扩大到所有用户。
这个过程是持续迭代升级的典型过程。
4. 成熟公司的核心产品的技术大升级过程
通常是业务及技术架构方面的大手术，大动作，包括自建开发团队长期开发的产品（业务系统）开发，以及（甲方）项目整体外包的开发。不像创业公司的试错产品，成熟产品的功能需求相对比较明确。会有新功能、新指标，但也都比较明确。这种技术升级的难度在于技术的实现（新技术体系架构的应用）、风险的把握（别弄成个坑把自己埋进去），所以在开发阶段需要大量的技术研究、测试、验证，提前把坑都基本填完。即使安排了新的架构开发，这个开发过程也是新架构的逐步迭代过程。如果一个老大听说了某个架构，或者某种技术体系，没有代码层面的把握直接上马，那就应该做好心理准备自己下课。
5. 大学或商业公司研究部门的技术升级过程
这个可以跳跃性比较大，但是真的能出来一个可供工业界作为基础，可以在其之上进行商业化开发的原型产品，没有长久的逐步迭代过程，填完绝大多数的坑，也是很难被采用和选中的。
基本上，一个产品，即使从外表看起来某一天横空出世，一鸣惊人，其内部开发过程，基本也是大量迭代的结果。从技术角度来说，一个大版本的开发，是若干小版本的开发的总和。
二、整个行业的技术升级过程
整个行业就是由技术创新与商业化逐步推动发展的，由无数的细节迭代实现的。
业务功能的实现大概可以分为业务逻辑处理程序和数据存储两部分。从行业整体来看，技术升级过程大概经历了如下阶段：
1. 小型机（以及大机）
价格高，大公司及大学买得起，主要处理公司的商业事务和大学的研究、计算。一台主机，多任务（进程/线程）。个人通过（简易的）远程终端连接到主机上，业务逻辑处理程序在主机里以任务（进程/线程）的模式运行，个人数据的以及多人的协作数据也保存在单一主机里（简单的文件安全机制）。
2. PC 个人电脑
价格低，个人家庭买得起。早期单任务，后来升级成多任务（进程/线程）。交互界面从纯文字升级到图形化界面。个人业务逻辑处理程序（如文字编辑、照片处理）和数据（文本文件、自定义数据格式文件、数据库文件）都保存在个人电脑里。
3. CS 架构
Client - Server，客户端 - 服务器端。
客户端是个人电脑，服务器端是性能增强的个人电脑，通过局域网连接在一起（大公司通过广域网连接起来，类似局域网）。
价格低，小公司、大公司的小部门买得起。业务逻辑处理程序（公司内各种办公软件）运行在客户端的个人电脑上，数据大多以数据库的形式存在服务器端，数据的隔离以及安全机制由服务器端的数据库软件实现。
4. BS 架构
Browser - Server，浏览器端 - 服务器端。
客户端是个人电脑上运行的一个程序，浏览器程序，电子邮件客户端程序，电子游戏，聊天工具，等等。服务器端是放置在数据中心（由电信运营商等建设）的小型机，或者运行小型机系统性能升级的个人电脑。服务器逐步发展到现在，主要运行从小型机延续下来的类 Unix 操作系统，Linux。
互联网在研究机构、大学和大公司持续普及，技术的持续发展，尤其是通过图形化界面的浏览器程序访问远程小型机的上的数据文件，即 Web 访问方式（内部HTTP协议），让个人与商业公司的信息交流、服务交互，成本大幅度降低，大幅度的推动了互联网商业的发展。
业务逻辑处理程序主要运行在服务器端，由专用的 Web 服务器、应用服务器完成。数据也主要保存在服务器端，早期是 CS 架构下的数据库，现在已经发展出来越来越复杂的数据存储格式及分布方式。个人电脑上的客户端程序，电子邮件、电子游戏客户端等，完成一部分业务逻辑，保存一些属于个人的数据；浏览器，在浏览器里面的运行的程序，完成一小部分业务逻辑，保存少量数据。
5. 移动互联网架构
无线网络的普及，数据通信速度提高价格降低，以及手机硬件的发展，个人电脑尺寸缩小成了手机的大小，推动了 BS 架构的应用在手机上的大幅度发展。之前在办公桌上才能使用的个人电脑的各种业务逻辑程序，现在可以随时随地的在手机上处理，于是应用程序以及与之配套的商业服务，大幅度增加。
无线互联网的大量用户同时在线，大数据量大业务量，以及大量业务数据沉淀后开始的大数据分析与应用，进一步推动了 BS 服务器架构的升级发展。业务处理逻辑程序越来越多，互相协作关系（内部互相请求/响应）越来越复杂，相应的数据存储也越来越复杂。数据格式也在适合传统数据库存储的便于计算的结构化数据之后，发展出来便于商业优化、商业分析的非结构化数据等。
BS 架构、移动互联网架构的大概发展路线如下：
浏览器端 / 支持网络协议的终端程序 + 应用服务器 + 数据库
浏览器端 / 支持网络协议的终端程序 + Web负载均衡（服务器） + 应用服务器 + 数据库
浏览器端 / 支持网络协议的终端程序 + Web负载均衡（服务器） + 应用服务器 + 缓存服务器 + 数据库
浏览器端 / 支持网络协议的终端程序 + IP协议负载均衡 + Web负载均衡（服务器） + 大型单一业务处理（Web负载均衡（服务器） + 应用服务器 + 缓存服务器 + 多种数据库） + 大型单一业务处理（Web负载均衡（服务器） + 应用服务器 + 缓存服务器 + 多种数据库） + 。。。
6. 大数据架构
当业务量、数据量，包括沉淀量，增长到规模巨大的时候，数据的存储，对数据做计算，例如搜索引擎对大量采集的网页做搜索，电商网站在所有商品中对特定购买需求做搜索，SNS、微博等对内容做搜索、热推，广告投放系统做目标客户影响分析与投放决策，大工业生产系统对所有生产数据（包括传感器信号）做运行检验与调度优化，等等，难度都大幅度提高，生产系统实时产生数据与动态大量计算同时存在，因此对于业务逻辑处理程序的分布、数据存储的分布等需要重新组织，但成本又不能大幅度增加。
大数据相关的业务是公司中的单一业务（可能是核心业务），在尽量解耦和的思路下，把不可能再细分的、不能单独把数据复制分离出去（业务处理程序分离出去）的系统，做成单一业务系统，单独进行架构设计（单独持续优化），在公司内以独立的业务系统提供内部服务（可以实现成 WebService 等 RPC 接口）。
从公司业务角度看，数据量很大的单一业务的架构，是 BS 架构的一部分，偏上层的业务部分。
从技术实现角度看，处理大量数据的分布存储及标准逻辑分布计算的架构，可以作为基础技术部门对其他部门（也可以对外提供服务）的业务接口，类似云计算或者云平台中的单独模块，独立承接需求方的需求升级，独立优化升级（如为大型模型提供GPU计算、开源芯片计算、高可靠高安全计算）。这一部分也是 BS 架构的一部分，偏底层的技术部分。
7. 物联网架构
社会环境中的无线网络的大量普及，数据通信费用持续降低，硬件（尤其开源芯片）的继续发展，成本降低，让各种设备上的控制电路模块越来越智能，通过网络远程协作，组成更大业务系统。
物联网的架构基本基于 BS 架构、移动互联网架构。物联网的设备端的架构正在快速的迭代发展中，从操作系统、网络协议到业务软件等正在竞争。物联网的服务器端软件可预见的将来还是 BS 架构、移动互联网架构的服务器端。
8. 人工智能架构
人工智能是在大数据基础上，利用程序对大量历史业务数据做分析，训练出来业务模型处理逻辑，并以处理逻辑对实时生产数据进行处理，计算出来的决策结果优于人类智能，然后被允许自动进行操作，为人类获取更大的效率与收益。目前在信息搜索、用户分析、金融交易等领域开始大规模使用。
到目前为止，人工智能基本是 BS 架构的服务器端的众多业务处理逻辑程序中的一个，未来大概会让公司客户或者个人付费购买服务。因为人工智能的分析及决策结果的计算严重依赖于计算量（追求更优解），所以可预见的未来，个人设备端与服务器端，从芯片到操作系统到应用业务等架构，会持续优化，降低成本，提高效益。
三、结论
1. 不要一步到位，不要一次解决所有问题（跟产品部门、销售部门、运营部门明确一个最小的必须实现的需求集）。
2. 不要给自己挖坑把自己埋进去（架构大爷们，不要自己骗自己，自己吹的牛逼是要实现的）。
第二原则，符合业务原则
本原则是用于（业务）产品的开发过程。（架构师所需要的）技术架构的开发过程在第五原则。
一、业务成长过程
一个公司的开发部与市场部、运营部的分界点，是产品。
产品负责人需要负责把产品做出来（组织安排开发部），然后把产品卖出去（组织安排销售、运营部门），缺一不可。在产品开发方面与产品销售、运营方面做平衡妥协（因为公司的资源、人力物力有限），是产品负责人的第二重要的工作（第一重要的工作是把握产品的战略走向）。所以产品负责人是公司的实际总负责人，通常是总经理，老板。
但现实情况是很多人创办公司（或被委任为总经理）不是因为对产品了有战略判断、对产品开发、产品销售有了丰富经验才开始的，而是有了一个方向的突出技能，比如开发能力，或者销售能力，还有可能是脑子一热或者某种雄心壮志（也有悲愤无奈、被逼无奈），或者干脆就是只有钱，只想玩一下试试，等等，于是就开始启动了，很多后来居然也成功了。这个大概是更符合人类发展的创新创业本质。那种很多能力都锻炼具备好了，然后出来自己创业的，可能是个假命题，更大的可能性是在锻炼他的那个环境里继续承担要职，或者换个公司继续承担要职，带领成熟的各部门各种团队按部就班的运行。
所以一个公司的长期产品开发过程，本质上是一个产品经理的长期成长过程。
产品经理能够成长多快，产品的功能就能成长多快，而不是开发团队能够干多快，或者架构有多先进多牛逼。
从技术角度来说，好的架构一方面能够实现业务（做出来产品），另一方面大概是能够降低开发团队被产品经理和市场销售部门、运营部门虐待折磨的压力。
现实中技术出身的老大经常有好架构并且不断的优化技术架构，最后死在销售上，表现出来是现金流完蛋了。现实中销售出身的老大维护了太多客户关系并且不断的跟客户搞好关系，最后死在对合格产品开发的漫长绝望等待中，表现出来的也是现金流完蛋了。
如果你的老大是技术出身，架构认识和能力很牛逼，那你会很舒服，干活各种自在，不过你应该更多建议他把精力放在产品和销售上。
更多情况是，国内，大多数的技术出身的人当不了老大。研究客户的、明白产品需求的、销售出身的人是公司老大，而架构师，就是跟着老大一路各种反复折磨反复验证产品的人。技术开发团队的工作，就是用技术能力陪着产品老大（其实更多时候是连产品定义该归自己负责都不懂的，或者懂也没能力的，销售老大）不断修改设计修改代码的过程。架构设计工作，就是给技术团队的开发人员们弄一个又快又简单又尽可能少被折磨又能实现各种（不可思议）功能的开发方法。
所以架构师（一辈子只会干技术的）成长有两个阶段。第一个阶段是对开发工具、语言API玩到非常熟悉了，可以藐视同行，可以在技术人员面前吹牛逼，可以用各种新概念新架构、上游厂家的新产品吊打秒杀手下们。第二个阶段是能够明白公司老大其实是技术智障，然后能够带着手下兄弟们给智障老大又快又好的出活，配合智障老大的各种智障试验试错，不断从智障锻炼成越来越明白的产品经理，在智障疯子的现金流完蛋前，一起把公司做出来利润，度过一次又一次的大的市场起落，抓住关键的市场机遇期，发展起来。
总的来说，一个公司（或公司内一个新部门）如果活下来了，稳定占据了一定的市场份额，大概经历的过程可以分成四个阶段：原型、产品、业务量质、降成本。
二、原型阶段的架构设计
技术出身的老大创办的公司（或公司内一个新部门），已经基于技术优势有产品原型了（如某个中间件、算法等），可以跳过此节。
原型阶段是公司（新部门）老大只有市场战略，有个大概的产品想法，或者见识了同行的、国外的类似产品，然后想做出来一个具体看得见摸得着的产品，产品定型之前的过程。
原型阶段的核心问题是产品功能（及目标客户）的确定。
产品功能确定的过程，是各种功能细节的反复展现、改进、增删、自己内部验证、找客户验证的过程，往往是从一大堆混乱的混杂的各种功能细节（经常来自于突发灵感、头脑风暴）中，慢慢提炼出来核心功能的过程。
这个过程中，在产品经理、市场销售运营人员、邀请来的典型客户，以及开发人员自身，持续的从各自的角度表达对产品的想法、意见、要求的情况下，开发人员要尽快的把大家的想法变成实际的产品。这个阶段，最快速的出来一个“东西”，让大家可以测试、试用，继续讨论，是最重要的。
这个阶段不用太在意产品的技术架构，只要产品大概能用就行。
技术水平高的架构师在这个阶段不要把重点放在秀自己牛逼的技术架构设计能力方面，界面架构、数据库结构/分布、网络协议、中间件等等，都可以找最快的方式来实现。如果自己从头做有难度，可以直接找类似的开源实现，或者花钱购买商业版的源代码。如果还不行，可以花钱买商业版的源代码团队的技术服务。
技术水平一般的，或者水平比较低的开发人员，尽自己的最大努力做就行了，也不要太在意架构方面的问题。这主要是基于两个原因，第一个是在产品（在市场上）验证成功后，整个团队会请来水平更高的架构师来带领你做架构设计和优化；第二个是，你可能因为出活出得太慢（尽管你已经干到最累最辛苦，发挥了最大能力），在后续的产品大技术升级中被开除了（员工持股会大幅度改善这种内部合作关系）。
当然现实的更多情况是在原型阶段被整体证明失败了，无论是独立创业公司，还是大公司的创业部门，所以开发人员的比较好的做法是配合产品经理、市场销售、运营团队尽快的改进产品，在钱还没烧完之前，迭代出来真正被客户需要的（愿意付钱）购买的产品。
在原型阶段，完全委托外包团队来做出来一个原型的做法，仅适合于特定的市场和产品。原型阶段的结果除了有一个客户能接受的产品，还应该有一个能继续迭代开发的团队。这个是销售出身的老大经常不太懂的。技术负责人、架构师应该多花一些时间把这个给老大讲清楚。而且现在的很多外包团队一般只对工时负责，对于配合甲方做产品迭代，思路和意识方面都不一定能跟得上。
经常有老大觉得某某创业公司、创业团队的产品刚一出现、一出手，就是看起来用起来很舒服，水平很高，开发团队应该给科普一下，这种情况有两个原因：一个是对方请了牛人高手来做，第二个是更关键的是，对方在内部的迭代过程你们没有看到，等到人家原型阶段迭代完了，给你看到的，已经是产品阶段了。
现在互联网时代，客户与产品创业团队的关系可能会紧密的多，好的创业团队在创业初期就持续发展“典型客户”参与原型阶段的开发，这个对架构设计没太大影响，但对快速迭代有更高的要求。一个“典型客户”对创业团队的信任，一开始更多的来自团队的反应速度，也就是“典型客户”给团队提供了意见后，多长时间会反映到产品设计里面来，这个对于“典型客户”的参与积极性，是非常重要的，所以这种情况下，“快”更是维持整体合作的关键因素。
从市场角度，一个创新商业时机的到来，机会窗口期一般都很短，一般会同时出现多家创业团队，最后哪个创业团队发展更多客户，占据更大的市场份额，哪个就活下来了。在这个机会的互相竞争里，“快”，几乎是最主要的能力。
三、产品阶段的架构设计
产品阶段是经过原型期的市场（客户）初步验证，产品功能基本确定，市场与客户基本确定，公司开始在市场销售、运营端起步的过程。
在产品阶段，技术部门的核心问题是产品质量的提升，让初期客户体验产品时少遇问题，开始体验新产品带来的愉悦感；让市场销售、运营团队开始放心的推广，不会刚在媒体上吹完牛就被产品质量差评打脸，刚谈完渠道合作就被毁约、退货。
支持产品功能的架构设计，是这个阶段的重点。经过原型期的的快速迭代，用户界面展现、业务逻辑、后台管理功能等基本定型之后，开发团队可以在边继续迭代功能的同时，安排架构设计师开始整理、重构、规范已经写出来的代码。
架构设计的工作从这个阶段开始越来越重要。
这个阶段的架构设计主要解决两个问题，或者是架构设计的两个目标，第一个是“不死机”，第二个是容易升级。
1. 产品“不死机”
在代码方面，无论用什么语言，Java、PHP、C/C++，或者 Python 等等，对于业务逻辑中的意外处理，思路基本都是差不多的。一个产品，一个无论大小的技术系统，稳定运行的前提是所有的意外情况、错误情况都有响应的处理，并且可以追踪，否则就各种不稳定，以及不稳定后都不知道死在哪里了。
在技术团队协作方面，架构师制定代码规范，以及代码 Review 协作机制，并且亲自监督运行。
后续的产品测试、试运行、内测、公测等阶段，架构师都要深入参与，通过各级反馈来修正架构设计，发现及解决问题。
基本上，互联网产品在生产中，或者消费产品在客户使用中，遇到问题，架构师应该承担技术方面的主要责任。
2. 容易升级
在代码方面，架构师以对功能的深刻理解，对功能的未来走向的超前认识，自己负责代码的技术架构的提炼与整理，适度超前于程序员正在实现的功能，并引导程序员在代码中逐步采用新架构。
架构的逐步升级有两个原则。第一个是要架构师本人自己写架构（框架）代码，第二个是让程序员更容易的在架构上进行业务升级的开发。
架构师自己不写代码，只是听说了某个新架构很牛逼，然后代码部分自己也没太看懂，自己也没有做足够的测试验证，冒然引入开发团队，会造成灾难。架构师也不能玩权力手段命令手下写架构代码，否则一旦出现架构级别的问题自己会死得很难看。架构师自己的命运在自己的代码里。
好的架构应该让水平一般的程序员也可以开发出来好质量的代码，让代码逻辑清晰，业务逻辑运行顺畅。不好的架构可能会引发程序员痛苦的离职，所以架构师做架构设计时要做好心理准备，最后可能是自己一个人填补程序员离职后留下的开发工作量。
在产品阶段，产品的功能虽然不像原型阶段频繁的大幅改动，但是市场销售、运营部门还是会不断的有天马行空的扩展功能、辅助功能不断的在产品功能基础上做叠加测试，所以好的架构还是可以大幅度促进产品的升级换代，或者小版本的迭代。
技术架构的大升级，要慎重，最好跟随产品的大版本升级一起进行。
每过一定的市场周期（通常一到三年），产品需要一个大的升级，给客户提供新功能、新感觉，公司的产品经理会安排大的升级计划，架构师储备了很长时间、做过足够测试验证的新架构，可以实施在这个过程中。
有一个问题要注意一下，产品的好用（好的用户体验），这个问题是开发团队经常收到的投诉抱怨比较多的问题。其实这个问题更多的是在产品的功能定义、用户交互设计、体验设计等方面决定的，更多属于产品经理团队的范围，开发团队只是实现者。不过有经验的架构师，包括项目经理等，在领导开发团队的过程中，会在功能细节及交互细节方面也尽可能完善一下。
产品阶段的架构师也可以称作应用开发架构师（API架构师）。
四、业务量质阶段的架构设计
业务量质阶段是产品稳定，销售市场、运营团队全力开拓市场，到市场份额基本稳定的过程。
量质，是指业务的数量（访问量、交易量、计算量等），以及产品（及服务）的质量。
业务量质阶段，技术部门的核心问题是支撑业务量的巨大增长，面向个人消费者的，通常是百万、千万、亿级等，面向正在到来的物联网设备的，预计会一直到千亿级别；在支撑巨大量的同时，产品服务质量、客户体验质量又不能下降，这个难度在目前的技术体系内，是比较高的，近些年的架构技术的发展，主要围绕这个问题展开。
对于销售出身的老大，这个阶段是生意发展的一个很大的台阶，自己一直没理解这个问题的解决办法（到处咨询了之后），也没有组建相应的架构师团队来解决问题的，基本都止步不前了。
这个阶段的架构设计，对于做产品阶段架构设计的架构师，应用开发架构师（API架构师），也是真正的考验。
这个阶段的架构设计，是在掌握系统级开发技术的基础上，根据具体业务实际需求，进行特定的、有针对性的系统级优化，来逐步迭代前进的。
系统级的优化结果，体现给应用开发架构师（API架构师），为应用开发架构师（API架构师）提供底层的、系统级API或框架，来支撑业务量的增长。
比较理想的情况，应用开发架构师（API架构师）可以不需要理解底层的系统是如何实现的，只要知道自己的应用架构、应用程序可以横向扩展，可以分布式扩展，可以在给定的时间内得到底层的运行结果（函数调用返回），就行了。至于底层的系统，如协议处理、文件系统、数据库、缓存等等方面的扩展与分布、性能实现，完全由系统架构师来实现。
系统架构师（以及包括系统程序员的底层开发团队）不是自己单纯凭理论进行系统设计优化的（系统级的优化方向太多，如单纯的一个操作系统的内核协议栈的性能优化就有很高的难度、不确定性，以及成本），系统架构师进行的优化设计，通过应用开发架构师（API架构师）、应用开发团队的验证，最终以业务量、产品质量、客户服务质量来衡量验证。
系统架构师对于系统级的优化，是不能随便应用于生产的。因为影响太大，所以要进行足够长时间、足够量的内部测试。新系统架构的上线是公司的大事儿，需要各部门配合，应对各种问题、故障、投诉的大量出现。
公司内业务部门众多，系统级优化技术比较类同的公司，可以把系统级架构师合并起来，组建成单一的系统架构部门，为全公司服务。
系统级架构设计是真正的技术难点，这也是业务商业模式走到尽头的公司，遗留下来的核心资产，并且后续以此作为公司的下一代核心商业方向之一，建立竞争优势，推动建立下一代业务及商业模式。
一代公司，一代商业模式，走到尽头后（产品、业务已经过时，相应的应用开发架构及团队也将被废弃），到底是留存下来钱（用于下一代投资），还是留存下来系统级技术（推动下一代业务），这个是公司老大的战略问题。
五、降成本阶段的架构设计
降成本阶段是市场份额已经稳定后，公司管理层追求利润回报的阶段。
产品、市场的高速增长期已经过去，营业额已经不再大幅增长，创业团队的热情已经不再，创业老大甚至已经卖掉股份投入下另外的新创业机会，公司的现有经营团队已经基本被董事会掌控，而现在的董事会，包括主要股东，已经变成了财务投资人，当初有创业理想的、冒险疯狂的股东已经在股价高位套现走人去寻找新的风口，等等。
对于有理想的架构师和开发团队，这是个难过的阶段。其实有理想的技术老大、架构师老大也已经离职走人（不过公司正值盛名，公司形象各种光辉高大上，于是各种没经验的想刷好看简历、拿点儿稳定工资的技术人马正踊跃申请加入）。
经营团队的核心诉求是降低成本，实现利润。
降低成本对开发团队来说，就是裁人。所以留下来的架构师的核心问题是在人员减少的情况下，尽可能保持业务的体量与质量的稳定运行，继续修改 Bug，适度增加小的业务功能的改进。
到这个阶段，前期架构师设计中的良好代码规范（以及技术文档规范），会显得非常重要。经常的情况是，某个应用模块，或某个系统组件，出了问题，需要一个程序员去 fix，而这个程序员刚进公司三个月，刚熟悉业务，于是这个程序员来请教架构师老大，fix 那个问题有没有指导或者建议。架构师就要做好准备，那个程序员可能搞不定最后还需要自己出马 fix，而自己很长时间没弄那些代码，连数据结构、数据定义都忘记了，甚至根本不是自己写的代码，要短时间重新弄明白解决问题（还要别弄出来新 bug，否则自己就被开除了）。
在这个阶段，已经有一定开发能力的程序员，应聘成了架构师（或者前任架构师走了自己被提拔成架构师），就大量的阅读代码，熟悉已经在运行的系统架构吧，然后在尽量不把系统搞死（产品、业务搞死）的情况下，小心谨慎的添加新功能，开发和应用（自己实在看不懂前任的架构设计，不得不重新设计了）自己设计的新架构。
这个阶段，公司（从董事会到经营层）已经不再考察技术架构的先进性，只是要求保证产品、业务的运行。
六、结论
任何时候，架构设计要符合业务的需求，这是第一位的。
一、用你最熟悉的语言
如果你已经被任命为架构师了；或者根本没有架构师，你不得已必须承担写架构的工作；或者你觉得你的自己写的一大堆垃圾代码需要整理出来个小小的初步架构了，等等，反正你要开始做架构设计了，用于业务的实现及发展，增加轻松减少痛苦，那就用你最熟悉的开发语言吧。
这个行业经常有人在讲某种开发语言很牛逼，某些方面能力非常突出，是未来发展的主流，弄得你半信半疑、心神不宁、心痒难耐，于是你忍不住去弄个例子试试，买本书看看，进入社区混一些日子，等等，学习研究一下，这些都是挺好的。但是用在自己的工作中，真的要写出来用在业务中，为产品、客户、自己的饭碗负责，那还是慎重点儿好。
在没有做出来足够多的项目，包括学习项目、测试项目、实验项目之前，不要在架构设计中用新开发语言。
如果真的觉得老的语言太陈旧了，各种不方便，那可以在架构的某个局部，某个小功能，小小的开始试用、实验新语言。
换语言对一个程序员是一个大事儿，影响自己未来十年的职业发展。对一个公司来说，换语言几乎就是公司的开发团队全部开除再全部重新招人。一般只有新功能、新部门才比较合适；或者公司大了，实力雄厚，可以承担这种折腾和风险。
对于应用开发程序员，语言就是自己的命脉，因此，也是自己设计架构、考虑业务实现方式的命脉。
应用开发程序员工作多年后，除了把语言掌握到非常熟悉，把基于语言的某些行业内主流架构玩熟，还会沉淀下来自己实现的某些功能的模块或架构代码（自己在某个领域工作了很多年后的结晶）。比较能干的程序员还可能会把自己写的架构发展成独立的产品去市场上销售（这是上一个原则里说到的情况）；或者以自己的架构为基础，带领一班兄弟去做外包开发；或者放到开源社区，与其他程序员一起使用一起协作继续开发。
应用程序员除了语言熟练与架构积累外，还会积累下来把业务需求转换成代码的能力。
二、明确业务需求
承接上一个原则，符合业务是第一位的。
具体的实现业务，就是跟业务人员，包括产品负责人（老板、产品经理）、市场销售与运营人员等，一起商量产品的具体功能。具体功能一般由一大堆用户交互界面和操作流程组成。
用户交互界面，可能有最老的字符界面，有图形时代（CS架构）的窗口界面，浏览器时代的网页界面（BS架构），窗口内嵌的浏览器界面（CS-BS混合架构），手机时代的APP界面（原生的APP与CS时代的窗口界面很类似，APP内嵌的浏览器则类似CS-BS混合架构），物联网/AR/VR/语音/视频采集分析/动作采集等等新时代的人机交互界面。
操作流程，是交互界面的切换。用户在一个交互界面进行了什么样的具体操作，触发下一个对应的交互界面的展现。某个业务功能的实现，是用户通过连续的交互界面的操作来完成的。
这些交互界面与操作流程，是给用户直接感受的东西，需要跟业务人员反复商量讨论，把各种细节确定下来。
技术开发团队，包括架构师、项目经理、技术部门负责人，一直到CTO，跟业务团队，分界，协作分工点，就在交互界面以及操作流程的定义上。
经常的情况是，业务团队提出来某种需求，技术开发团队提供一种或几种技术实现方式供选择，讨论。
更好的产品设计，会在业务与技术实现的讨论中，加进来艺术设计（类似于工作服到时装），让用户对于某个业务的操作，全部操作流程以一种艺术感受体验的方式来完成。这个是增加产品价值的好方式。
在交互界面及操作流程没有定下来之前，技术开发团队最好不要开展后续的项目设计、代码开发等工作。
交互界面及操作流程的设计，包括其他的产品或业务流程的设计，是产品设计的核心。
一个公司或项目的起步，如果在交互界面及操作流程的设计阶段就说不清楚，一直讨论不清楚（这个问题在创业公司经常发生，几乎是主要问题），那架构师再牛逼的能力都没太大用处，自己可以考虑给下一个公司投简历了。
好的架构师，应该与项目经理、技术部门负责人、CTO等一起，坚持要业务部门一起工作，把交互界面及操作流程都定下来。
有的公司老大（或部门老大）觉得暂时想不清楚，会让技术开发人员自己参考别人的产品先弄一个原型出来看看，然后自己做选择或改进、增减。这个做法的效率比较低，属于老大在产品认识及把握能力方面能力不足，很难玩长久。
三、设计数据结构与程序流程
交互界面及操作流程明确之后，包括关键的业务规则、算法也明确后，白纸黑字写成文档，市场部去做宣传推广，技术开发部着手实现。
开发实现以项目来进行，按照项目管理的方式来管理。具体可另见本文的同系列文章《项目管理》。
架构师负责其中数据结构设计与程序流程设计。
1. 数据结构设计
无论架构师用哪种语言进行开发，这两部分的思路基本是一致的。或者说如果架构师已经经历过多种语言的开发，会明白其实开发语言之间的差异主要是代码组织、编程思路的差异，差异结果主要体现在开发效率以及代码质量方面，而对于业务的实现，主要的数据结构与程序流程，基本是一致的。或者说，无论你用那种语言，你最后都要实现交互界面信息的处理，以及操作流程的切换。
交互界面反映在代码里面，就是数据的组织、定义，以及数据之间的关系，组合起来就是数据结构。如果是面向过程的代码，比如 C 语言，就通过 struct 这样的方式来定义一组一组的相关性很高的业务数据；对于现在用量比较大的面向对象的语言，就通过类的方式来定义数据及其之间的相关性。
在数据的存储方面，数据结构跟关系型数据库结构设计、非关系型数据库K/V设计、数据缓存设计紧密相关。甚至对于交互设计比较简单的企业业务，交互界面几乎就可以归纳为对数据库的增删改查。
网络协议设计方面，数据结构的设计就是网络协议设计的基础。网络协议可以基于 TCP/IP 自己定义，也可以基于 HTTP/JSON、XML 等进行封装，但不管如何封装，保证数据结构的完整传输和操作流程中的内部状态保持，是必须的。
2. 程序流程设计
程序流程是与界面操作流程对应的。
面向过程的程序设计（如 C 语言），与面向对象的程序设计，主要是代码组织机制的不同，从操作流程实现来看，其实差别不是很大。
一个鼠标 Click 事件的响应代码，到底是应该写成一个文件里的单独的全局/局部函数，还是应该放在某个类的下面，写成方法可以被子类继承或重载，其实差不多。
一个 HTTP 请求的返回，到底是在一个单独的 HTTP 模块的某个文件的某个函数里，接收到数据包，根据协议定义的包头字段数据进行判断，调用对应处理的函数指针；还是在 HTTP 类的某个方法里，接受到数据包，根据协议定义的包头字段数据进行判断，调用对应的基类实例的同名方法，也其实差不多。
所以重复一下前面说过的，语言的差别其实不大。架构师做语言的选择，在选用了自己最熟悉的语言后，就是保证代码运行“不死机”，并且容易升级，这个也是前一个原则。
而代码运行“不死机”以及容易升级，主要是说普通程序员的代码。普通程序员在架构师的代码基础上、框架内，进行开发。能够让普通程序员的代码不出问题，而且能够轻松开发（这个对于老大节省开发成本很重要——如果只要招普通程序员就可以干出来好活的话），这个时候语言的差别就比较大了。给普通程序员讲明白类方法的重载，比讲清楚函数指针要容易的多，而且程序员对于类的方法重载写错的机会也少得多。
所以对于架构师，在自己用代码实现界面基本操作流程的框架之后，就想办法让普通程序员少犯错误，尽快出活吧，否则自己就没办法下班了。
四、同步/异步的抉择
应用架构师的真正挑战从同步/异步开始。
这是公司的业务规模增大了之后，到了业务量质阶段面对的问题。
因为系统规模的扩大，一个以前简单的问题，内部增加了很多不确定性，需要处理。
比如网上商城一个以前简单的订单提交，用户在网页上点击提交，网页用 Form 的形式提交给后台应用服务器，应用服务器的程序代码拿到用户数据后直接操作数据库，给数据库提交一个 Transaction，集中修改若干张表，记录一个订单的生效，然后应用服务器给用户返回下一个网页，包含订单的提交结果。
这样一个处理过程，从用户点击提交，到应用服务器处理完，到给用户返回下一个网页内容，在一秒钟的时间内返回，用户的体验是正常的，感觉不到什么问题。
手机 APP 也是同样情况，只不过手机 APP 里面的代码可能不是 JS，而是本地原生程序的代码，后续处理逻辑是一样的。
但在业务量大幅度增加后，无论网页提交一个交易请求，还是手机 APP 提交一个交易请求，后端的应用服务器忙不过来，或者数据库服务器忙不过来，或者业务复杂后，其他的环节服务器忙不过来，导致程序流程，在某个环节，被阻滞（Block）了。阻滞带来的问题，是各环节的函数调用，或者类方法调用，很长时间不返回。
很长时间不返回，最终会体现在用户交互界面上，比如用户在订单付款环节点击提交后，网页屏幕一片白屏，或者手机 APP 始终显示一个等待图标，用户就会越等越抓狂。即使最后等待了 5 秒钟后终于返回来结果了，用户的体验也不太好了。解决这个问题的办法，是把之前的全过程的同步等待的程序流程设计，改成异步流程设计。
异步程序流程设计，就是一个函数调用之后，立刻返回，并且在后台继续处理提交的业务。
对于订单的提交，异步流程后，用户点击提交，网页或者手机 APP 立刻响应，给用户显示一个提示：“订单已提交，请继续浏览商城，订单处理完毕后给您提示”，也就是网页并不刷新，手机APP也不处在死锁用户操作的等待状态，只是通过网页的 AJAX 方式、手机 APP 开一个线程的方式，向后端提交一个交易请求数据包。
后端应用服务器收到请求数据包后，先去一个数据库的分库，增加一笔交易请求记录，然后去操作交易数据库，提交Transaction，结果需要等很长时间，数据库才能响应，处理好了才返回，然后把订单交易记录的状态改成“已完成”。这个等待的时间内，如果用户心急了，去网页上查看自己的订单，会有另外的应用服务器响应，去订单交易请求的记录数据库查询订单状态，然后给用户返回“正在处理中”的状态，用户的心态和感受就会平缓很多。
等到后端的交易真的完成，一直在等待的网页的 AJAX 代码接收到后端返回的订单状态，在网页上给用户显示一个浮动提示，告知用户订单已成功。手机 APP 的通讯线程也是类似机制，通知向主线程发消息，通知订单已完成，手机 APP 给用户显示一个提示。
这种异步程序流程，代码的时序和状态维护的难度大幅度增加，对于程序员的要求大幅度提高，对架构师也是很大的考验。经常会发生业务运行进入到了“不可知”的状态，没人能说清楚到底是什么状况，发生了什么样的过程。调试起来难度也很高。
现实中，除非业务实在迫不得已，否则架构师不要轻易把程序流程架构引向异步模式。
或者是，即使必须要引入异步模式，也在尽可能少的环节应用。
五、业务子系统的发展
公司大了，业务量增长到巨大。围绕核心业务产品出现了越来越多的各种辅助业务、增值业务，程序流程越来越难规划协调。出现了越来越多的业务部门，每个部门都有自己的老大，有自己的开发成本预算，有自己的开发团队，都有自己的架构师；每个架构师都有各自的开发语言，都有各自的开发框架，有自己的前端代码与后端应用服务代码，有自己的数据库结构。
天天开会，天天吵架，协调，扯皮。
全异步架构，大概是解决问题的一个办法。
单一部门的应用架构师跟系统架构师合作，把自己的业务系统，做成内部独立的业务子系统，以 WebService/RPC 的方式，对其他业务提供服务，进而对客户提供服务。
业务子系统对外提供数据查询服务，也提供事务处理，类似数据库的 Transaction。
继续以订单处理的业务为例。公司内有成立了一个专门负责订单处理的业务部门。这个部门独立开发维护一套订单系统，对内提供服务。
服务的接口有订单的提交、撤销、查询、报警等基本功能。
订单的数据格式是跟其他业务部门共同协商好的。
服务的接口提供前端的网页端和 APP 组件端。网页端是嵌入网页的一个 JS 代码文件，负责客户端网页的部门，需要在网页上显示订单的功能，就安排一块显示区域，并调用订单网页端代码提供的 JS 接口函数，输入用户的 ID 信息，JS 接口函数就负责跟后端的订单子系统进行数据交互，包括身份及安全验证后，然后等待 AJAX 返回，把订单信息显示在网页的给定区域。在等待期，订单 JS 在显示区域显示订单正在刷新的提示。至于网页上的其他信息，订单部门不负责，代码部分也各自独立。
订单子系统的后端，应用服务器拿到订单的查询请求，或者订单的事务处理请求，如创建、撤销等，先放入内部的事务等待队列（数据库），然后自己循环查询等待结果。对于订单的事务处理，另外的单独的订单处理服务器，上面有订单处理进程，从事务等待队列（数据库）拿出来订单事务，在缓存中查询相关的数据（如产品信息），向其他的业务子系统查询并锁定产品库存信息、价格信息，预申请网银付款处理，预申请物流处理，等等，每一步都记录入订单的处理数据库，每一步也都是异步操作。对方的业务子系统处理结束后，会以消息的方式通知订单子系统，接收消息的服务器负责更新订单的状态。
等订单处理进程把订单的完整流程处理完，无论成功或失败，如果失败则包括失败信息（如网银付款失败），更新订单处理状态。此前一直在循环等待的响应前端的应用服务器，把订单完成信息返回给网页前端。
后续，各个部门的业务独立发展，于是各部门的业务子系统也独自迭代前进，架构也独自前进。
在系统架构师层面，如果各部门系统级的架构类似，可以成立系统架构部门集中提供架构支持。
六、结论
1. 用你最熟悉的语言。
2. 不到万不得已，不要玩异步模式。
第四原则，系统程序员原则
（此部分详细内容暂不公开。后续会在技术讲座中结合听众的具体业务情况讲解系统优化的方法。）
应用程序员（API程序员）是把（产品）业务转化成数据结构及程序流程代码，解决的是业务的实现问题。
系统程序员是把应用程序员所需要的API，用计算机系统资源和系统级代码实现出来，解决的是系统级的能力以及资源有效利用的问题。
一、支持应用 API
1. 采购商业（架构）产品
2. 采用开源（架构）产品
3. 自己研发系统 API
二、进程/线程的限制及其扩展
三、代码运行效率的提升及CPU的扩展
四、内存的合理利用及扩展
五、存储的优化及扩展
六、网络拓扑及协议的设计
七、操作系统的调优
八、分布事务处理
九、全局优化的平衡
十、全系统的坑在哪里
十一、结论
一、对现有业务的提前预期
被业务折磨到不行的应用架构师、系统架构师，为了在即将到来的下一个大版本升级中彻底解决纠结了很长时间的大问题、结构性问题，提前开始安排下一版的架构设计。
这个难度一般都比较高，弄不好会把团队和自己都弄死。平常跟负责技术的老大多沟通，甚至跟老板有机会也可以念叨一下，核心思路是尽可能多组织各种力量来解决架构大升级的问题，同时也说清楚自己的态度很愿意干，但是能力不一定够用。最后就算各级老大没有请来大神帮自己解决问题，也起码让大家知道，架构的大升级是有风险的。
业务体系的架构升级，架构师可以提前自己做各种准备工作，各种测试、验证。但是真的启动成团队行为，真的要安排开发计划，公司投入资源，那还一定要让公司老大与负责技术的老大全面平衡后拍板决定。
公司经营有很多环节，很多部门，每个部门一般都有积累的大问题、结构性问题。从公司的整体角度来解决，都是要花费成本，也都是有风险的。技术架构中积累的大问题，只是其中的一个。到底什么时候是解决的时机，解决到什么程度，要在全公司的整体经营架构内安排考虑。更别提公司老大们要不就不懂技术，或者根本不在乎你的痛苦与风险。实在不行出大问题了就换一批架构师好了（董事会一般主要考核总经理的经营指标，开发部门只是工具）。
另外，不好意思，你的架构运行得很痛苦了，天天有问题，天天着火，天天擦屁股，但那只是你自己的问题，该你自己负责。如果你的新架构设计，貌似把系统弄稳定顺畅了，但是把开发人员们弄得都很痛苦，大家为了在你的新架构上面把业务代码重写一遍，需要重写50%的代码，那对不起，大哥，你这个架构有问题（行业中有牛逼公司的传说，经常全部重写自己的业务代码，但那基本只是传说）。
所以，如果真的决定要做架构大升级了，那就尽量找最小规模的大升级，让自己、让团队、让业务稳定运行、让老大的钱，都可以忍受。
对于架构升级中的种种问题的全面分析与平衡把握，包括“不死机”与容易升级，是架构师能力的重大考验。
玩装逼的，玩单一指标做到极致的，甚至由此而整天抱怨这个埋怨那个的，统统玩不下去。
如果你作为一个架构师，真的认为公司的技术架构已经烂到不行，必须彻底推倒重做，而公司内部上下都不支持，但也都没办法解决，那你可能真的发现了新的商业机会，自己寻找机会离职出去找明白人来支持你跟你合作吧。这个意思是，用你的实际行动，来证明你对自己的架构认识的坚持。
二、行业新技术的采用
或者你购买的商业产品被商业架构公司升级了（架构），或者你采用的开源产品被开源社区升级了新版本，或者整个行业开始进行平台性转移（比如网页转向APP、转向AR/VR），技术团队必须跟上看看、试试，你这个架构师责无旁贷。
这个情况，就是你的上游架构师已经先升级架构了，你需要应对处理，从你的业务到产品逐步转移上去的过程。
这个决定和过程，也是先做小实验，小尝试，可以弄清楚对当前业务的整体的影响。然后跟市场、运营部门配合，判断清楚对公司整体业务的影响，然后一起商量是否要升级，以及具体的升级方式，比如从多小的局部开始尝试，逐步的成功后如何在全公司推广。
技术玩的年头长了，语言积累到很熟悉很自信了，对于某个原厂或开源社区的架构到了熟悉甚至崇拜的程度了，开发人员容易形成 API 依赖，平台依赖。一旦平台升级了，自己不升级，心理上就接受不了，觉得可能会落后，影响竞争力。有时候会在这种心理压力下，在公司内部推动架构升级，为此不惜开发团队经常重写代码跟随升级。对于这种行为其实没什么好办法，除非技术老大能懂架构师在说什么，否则就折腾吧，只是注意别掉坑里折腾死自己。
总的来说，行业的大技术升级，还是要跟随的，只是早晚与时机的问题。
三、技术团队自研了新产品
公司的业务不断发展，会带动出来新的附加业务，或者创新业务（比如电商带动物流、支付）。而有些业务，是开发人员能看到的，比如大数据分析、客户行为分析、人工智能等，技术团队可以以此开发原型产品，推向市场。
这方面架构师的机会比较多，因为很多这样的工具或者产品，本来是架构师为了解决自己的痛苦问题随手弄出来的（AT&T的程序员了为打游戏开发了 Unix，为了开发 Unix 设计开发了 C 语言？）。
架构师新弄出来工具，进而越来越像产品的时候，可以跟公司的市场销售、运营部门经常沟通展示，做内部推销。尤其是，技术人员做的出来的东西，在内部上线，可以有直观的运行数据做支持，比较有说服力。
对于这种机制，架构师可以希望公司有个“开明”的环境，能够鼓励自己不断的把新功能、新产品原型开发出来，然后市场销售、运营部门喜闻乐见，非常期待。但是，对于大多数天天被内部各种问题折磨得焦头烂额的公司，这种内部机制很难存在（纯技术公司，或技术老大创办的公司，会好一点儿）。如果技术开发部门真的做出来好的原型产品，那就要做好自己推广销售的准备。也就是，架构师做出来好的原型，说服开发部老大，继续投入资源做出成了自己的产品，之后要勇敢的去跟公司老大说，要内部创业，要自己承担成本及负责销售额。如果公司老大不同意不支持，那就准备自己去公司外面找投资找资源，自己创业。
没有能力用自己创业来养活自己产品的架构师，就把自己写的原型产品，静悄悄的自己用就行了。也可以经过公司同意后（要说服公司这个东东其实没太大商业意义）发到开源社区，给大家免费使用，让大家集体维护，降低成本，一起等待商业时机（被哪个商业老大看中进行商业化发展）。
四、结论
谨慎填坑，适度超前一点点。
第六原则，CTO 的原则
前面的五个原则，都是架构师的代码在整个产品架构中的协作方式。
本原则讲架构师本人在整个技术团队中的协作。
公司中除了代码的技术架构设计与维护，还有技术团队的架构设计与维护。架构师跟整个技术团队合作顺畅了，自己的代码也会顺畅很多。或者说，从团队协作的角度来看看代码设计方面的一些要注意的问题。
一、技术团队的架构
跟代码架构一样，技术团队的架构也是不断迭代组建的，也要以符合业务（实现业务）为第一目的。
所以实际上，技术团队的架构也是不断变化的，不断折腾的。不过还是有一些共同的经验总结下来，或者大概还是有一些习惯做法的。
技术团队的架构设计，一般由 CTO 负责。没有 CTO 的时候，一般由公司老大，或者开发部经理负责。
CTO 下面，包括技术部门（可能不止一个）经理（负责人），技术部门下面还有架构师、项目经理、开发人员、测试人员。自动化测试发展到现在，如果设立独立的测试部门，那也可以当作一个开发部门看待了。
CTO 对技术团队的所有方面负责，包括商业模式的分析与确定、公司计划的制定与实施、技术团队的招募组建、技术架构的设计、产品功能的确定、项目（版本）的运行管理、产品的运维与售后技术服务支持、技术部门总体成本的控制、团队工作评价考核，等等，以及，任何技术环节（无论是产品代码还是团队）出现的大问题的修复。
技术部门经理带领某个部门实现公司的某个业务的开发（中小公司一般只有一个开发部，公司大了才有多个），对单项业务的开发实现负责。
架构师隶属与技术部门，在技术部门经理的安排下设计架构，参与项目的开发。架构师对功能实现、技术架构，以及程序员们提交的代码质量负责。所以架构师可以作为组长（或副组长），领导一小队开发人员在自己的架构上进行开发（如Web前端开发组、安卓开发组等）。
架构师的技术通多个领域，技术能力很强，甚至可以跨部门进行架构设计、支持。可以发展成技术总监，对多个架构负责。
项目经理对产品功能（某个特定版本的开发）负责，具体是功能的实现与进度与质量的控制，组织架构师与开发人员开展每天的具体工作。
二、公司的技术架构规划
做技术架构设计的是架构师，但是对技术架构终极负责的是 CTO，出了大问题最终是要 CTO 负责解决的。
技术部门经理通常更偏向业务一些，或者就是天天被市场销售、运营拉着不停开会承担功能实现、问题解决的那个人，对于技术架构很多时候有心无力。
一个公司的技术架构发展是要有规划的，否则架构出问题 CTO 解决不了就下课了。所以，公司的技术架构，要在 CTO 的心里有个把握。
换个说法，CTO 的架构能力，决定架构师的架构能力发展的边界，决定公司的产品技术能力的边界（类似的，公司老板的能力边界，是公司发展的边界）。
所以架构师，在公司内做未来发展规划的时候，要跟 CTO 一起做。或者也可能是 CTO 拉着你一起做。
架构师日常的架构设计，最好经常在公司内做讲解，邀请 CTO 参加。
架构师对于未来的架构的发展构想，尤其是步伐可能比较大的，更要经常跟 CTO 讨论。最好一起做测试、研究，一起做实验项目。
从交易和评价的角度看，架构师所做的架构设计的真正买家，是 CTO，而不是自己手下的程序员，或者公司的其他协作部门。所以架构师要向自己的真正客户不断的介绍自己的产品（架构设计）。
架构师的工作成果在公司内部遇到问题，出现大 Bug，引发公司的大损失，遇到大的差评的时候，架构体系能够继续坚持下去，架构师本人是否能继续留在岗位坚持工作，CTO 的决策与支持是关键。
CTO 的核心职责之一，对技术架构负责，是跟架构师一起完成的，是拉着架构师一起负责的。如果架构师被开除走人，那 CTO 后续对架构的坚持也很有难度。
架构师与 CTO 协作，一起稳定架构设计，一起安排发展规划，是公司技术架构工作的核心问题。
三、CTO 的原则
像 CTO 一样考虑问题，开展工作。
CTO 是与 CEO 一起完成公司的业务指标、经营指标的，都是在有限的资源里，做出来尽可能完善的产品，然后不停的接触客户，做一单一单的业务，实现销售额、利润。
这个过程的不确定性非常高，难度、风险、问题是天天面对的东西。
其实更多的真实情况是，CTO 和 CEO 们，经常不知道下一步该怎么办，必须努力研究各种情况各种问题，不断的重新思考公司的发展战略，不断的思考与尝试产品的发展与了解客户的新需求。
这个意思是，天天在公司里发号施令的老大们，其实心里都是各种不确定性。
CTO 对技术架构的思考，架构实现的能力、走向、风险、成本、团队、协作，等等，天天都在反复思考。
从这个角度，架构师要明白，做架构设计，不能全听 CTO 的，也不能不听他的，要明白 CTO 也经常在巨大的各种问题之间权衡判断。
架构师自己不断的坚持自己的架构规划、设计，然后勇敢的没完没了的“推销”给 CTO，有助于增强 CTO 的确定性，以及信心。
好的架构师，不能只做纯技术的不跟人说话只提交代码的技术宅，应该在自己牛逼代码的基础上，积极的勇敢的在公司内吹牛，推销自己的技术架构，靠不断的被差评、不断的被打倒、不断的重新改进设计、重新上线，支持团队和产品的发展，以能力和斗志服人，尽早替换掉已经写不了新代码、做不出来新产品的 CTO。
四、结论
与 CTO 一起做架构发展规划。
如想就本文的内容进行讨论，或其他合作，请发邮件到：service@xyouwork.com
