CTO要了解无线技术/搜索/大数据/数据库等。
通常定义架构有几个层次，这包括业务架构、产品架构、应用架构和技术架构：
1.业务架构：描述一个企业围绕一个行业做了哪些业务，例如支付行业的收单、退款、出款、充转提等能力，这与公司对外和对内定义的产品无关。
2.产品架构：描述对外和对内定义的可销售的产品，例如微信的条码支付、扫码支付、公众号支付等。
3.应用架构：描述提供了哪些系统和服务来实现对外和对内的产品架构，从而支持公司的业务架构，例如微信内部的订单系统、支付系统、账务系统和对账系统等等。
4.技术架构：通常涉及采用什么的技术栈，以及各个技术栈之间如何分工和协作的，具体会细分为数据架构视图、服务化架构视图、缓存架构视图、消息架构视图、安全架构视图、性能架构师视图等等。
作为通用架构师应该有众多的能力，这涉及到方向、战略、策略、决策、影响力、规划等。
对于技术人员在职位上的晋升，我们通常通过点线面体来类比，这也是从工程师到架构师的晋级过程：
点：能够独立负责一个模块的开发。
线：能够根据设计，同时负责一个项目中多个模块的开发，甚至独立负责一个项目的开发。
面：在所在领域内，可以负责一个产品的整个研发过程，并对业务和技术要有前瞻性。
体：能够负责一个产品线的研发过程，并且能够开拓某个行业。
架构能力，我们通常通过深度、广度和高度上来衡量：
1.广度：要有全栈的技术知识，针对所在领域的技术要有全面的了解，能够评估各种技术的优缺点，要能根据优缺点来做技术选型的决策。
2.深度：要针对所在领域的核心技术有一定的造诣，阅读过源码，针对产生的 Bug 要有能够迅速定位的能力，或者曾经贡献过核心代码。
3.高度：能够理解业务的本质，能够识别业务的风险，并做出合理的应对，对业务和技术都要具有前瞻性。要理解业务的本质，对业务的特殊性有所把控，要能抽象事务也要能具象事务。要能用技术服务业务，或者推动技术的更新换代，或者推动业务创新，从而直接产生价值。
管理模式：架构师要理解和适应各种管理的方法，通常有传统的多层企业管理、扁平化的企业管理、矩阵式管理，一般情况下，扁平化管理的效率较高，沟通成本较低，适合初创企业，在这种管理模式下，架构师也比较容易发挥其价值。但是在多层的企业管理和矩阵式管理中，由于层次较多，沟通成本增加，一项事情从上面传达到下面要经历多个中层领导，中层领导需要一层一层往下传达，传达过程其实也是一种成本，对于每个任务和项目需要沟通确认达成一致，才能保证项目传达的方向的正确性，由于层次多了，沟通成本增加，再由于中层领导区分战略思维，或者有战略思维没有落地经验，就会导致底层的人有可能没有完全获得上层人交给的任务，在下面就有可能“憋死了”，这些都是管理上的通病，架构师必须理解所处的环境，已经产生的问题，针对这些问题来提供合理有效的解决方案，毕竟组织架构也属于架构的一部分。
架构师素养
分享一个架构师的成长阶段。第一个阶段应该是习惯养成阶段，应该注重于培养良好的编码和设计习惯，注重代码量和代码质量，注重抽象；第二个阶段应该是培养模块和系统设计能力，在关键系统设计上总结方法积累经验，懂得资源（网络IO、磁盘IO、内存、CPU等等）如何最优化利用，系统如何分层，掌握可用性、高并发、高性能的一些方法论和设计技巧；第三个阶段是培养业务思维，能站在业务需求角度思考系统架构的合理性和架构演进方向，能发现影响业务发展的系统瓶颈；第四个阶段架构师应具备产品思维。
十位值得关注的Java顶级专家-
专访架构师陈波：微博近几年的架构演进之路和架构师的技能素养-
个人对架构的理解是这样的：
从开发人员的角度，架构是系统整体结构的规划设计，也是系统实现的一个草图，主要包含抽象出来的模块、交互协议及设计决策。因为架构的模块、协议、决策是抽象层面的规划，所以具体实现跟业务相关，要考虑业务的需求与特性，还跟业务发展阶段相关，要考虑业务当前的规模及发展阶段，选择合适的实现方案，必要时对当前的架构做适当的修改和演进。所以，架构是设计出来的，更是演进出来的；另外没有最好的架构，只有更适合（当前业务场景和阶段）的架构。
关于架构师如何定义：
架构师负责设计系统整体架构，确定系统实现的行动纲领，使设计的项目尽量高性能、高可用、易实现，并且在上线后运维方便，在新功能加入时扩展性良好。
架构师的能力要求：
1.较强的代码能力，对日常问题有丰富的阅历及解决之道，设计不是空谈，需要实践，代码能力、解决问题的能力是系统实践的一个副产品；
2.较好的抽象能力，业务需求在架构师消化后，需要转化为设计蓝图，这中间需要大量的抽象。
3.良好的沟通和组织能力，架构设计出来，需要组织讨论、频繁沟通，让项目组成员理解架构组成及设计取舍的原因，明白架构设计中的how和why，在遇到疑问、反对、建议时，能进行良好的沟通并有序的推进。
4.较好的团队协作能力和领导能力，架构师需要得到项目组成员的认可，在关键时刻对技术的选择作出及时、有效的决定，并为决定负责。
架构师的主要职责：
1.把业务需求转换为实现架构，定义每个组成模块的外部特性，比如它的依赖、性能、异常处理等，并确定模块之间如何通信，最终形成可以指导业务开发的行动图。
2.组织讨论，组织更多的人来了解、讨论架构，能够让大家理解架构整体方案、模块特性及边界、决策权衡点，进而可以自行进行组件服务的设计及实现；
3.协助项目经理制定开发计划和控制项目进度；
4.确定系统的基础架构、实现技术，必要时组织技术调研和攻关。
Java架构师之路：Java程序员必看的15本书的电子版下载地址-
高效的程序员：
熟悉不同的代码结构和设计模式。有一套自己的工具或者方法论了(带有Debug功能的编辑器)。高效率的程序员都把时间花在制作工具上。好一点的编辑器.系统性的思考方式.
适合CTO修炼的书籍：《六顶思考帽》-思维训练；《少有人走的路》-心理修炼；《创新者的窘境》《创新者的解答》-企业战略修炼；《定位》-自我定位修炼的书籍；《卓有成效的管理者》-管理方面的修炼；《麦肯锡方法》-工作方法方面，提高工作效率；《一网打尽》-企业文化。
CTO首席技术官职责：发展战略，技术总监，团队提升，团队建设，项目管理，产品管理等。
成为架构师：http://codebay.cn/post/939.html
小团队一般 10 人左右，其中常常是技术最牛的人做架构师（或 TL）。所以，架构师在广大码农中的占比大概平均不到 10%。而架构师也可以分为初级、中级、高级三档，江湖上真正高水平的软件架构师就更少了。所以，大部分（超过九成的）码农干上许多年，还是做不了架构师，这是什么原因造成的呢？
1：码农分为真的能写代码的，以及自认为能写代码的。
2：真的能写代码的码农又分为自认为写的不错的，以及真的还不错的。
3：真的能写不错代码的码农又分为会钻研会不断优化的，以及安于现状的。
4：会钻研的码农又分为喜欢广度了解新技术蜻蜓点水的，以及深入钻研用到知识的。了解广度的码农又有少部分愿意深入某些技术，喜欢深入研究的又往往缺乏广度知识。
5：极少深度广度都关注的码农又分为为技术而技术和为业务而技术的。纯为技术而技术的码农在国内的软件行业需求太少，且需求的往往不是应用软件领域了。
6：为业务而技术的深度广度都了解的码农，又需要有良好的沟通能力。
7：而沟通好的，又有一部分当 PM 去了。
8：然后剩下的，又有一部分慢慢脱离实际开发（不再做任何实现）或者开始依靠拿各种中间件搭积木来作为“架构”手段。
9：除去这些，剩下对业务有一定了解，对技术广度上有多种涉猎，深度上对部分技术研究彻底，还有很重要的一点，考虑问题足够细致全面。
10：细致全面善于沟通，技术上深度广度都没问题， 又喜欢这个工作，还会不时做底层实现，从业务和开发两个角度出发，搭出“架构”来是为了开发效率，为了运行效率，为了开发质量，为了业务灵活和运行稳定，为了维护方便等等这样的人，个人认为可以称为“架构师”。
而真能满足这种需求的，别说题主的 10% 的比例，1% 能不能达到我也持怀疑态度。其实现在的“架构师”大多数都停留在 8 这个层次，甚至很多在 5 这个层次就当上 title 上的架构师了。
总之，成为架构师，不仅仅是工作上的简单积累，更需要主动接纳工作外的大量知识，同时，对性格上对于非技术能力上也有一定的要求，不仅如此连思维方式都很重要，外加职业发展中又有很多岔路，最后走到架构师这根树枝上的就寥寥可数了。
金字塔结构
自古以来，金字塔结构（人群分个三六九等、高中低三档）在人类社会的各行各业中普遍存在，这是客观规律。恐怕再过千万年，也是如此。
人类社会为什么普遍、长期存在金字塔现象？其他动物，比如蚂蚁、大雁社会，有吗？这个问题就很深了，刨根问底有难度，也许应该问上帝。
金字塔结构 / 现象从根本上决定了大多数人做不了软件架构师。不光软件工程行业如此，能做技术领导的始终必然只是位于中上层的少数人。
英文水平差
据说中国有 700 万码农，英文不好似乎是一个比较普遍的现象。英语，尤其读写不好，把合格的架构师候选人选砍掉一大半。
小富即安的心理
很多码农每月拿到万把块钱，就心安理得了，不再有更高的追求。求稳求安定，这符合大多数人的心理。不满于现状，坚持不断学习，努力提高自己的开发技术和管理水平，拥有强烈进取心，想一朝一日做编程高手、软件架构师的人毕竟是少数。
二三流企业的压制
架构师不是随便什么人可以做的。在一个企业团队里，架构师作为研发和管理骨干，具有特殊的地位和权利。
知识结构的缺陷
架构师，程序员， 产品经理的区别，大概就是建筑行业里建筑师，建筑工人，甲方业主的区别。产品经理说我要建这么这么一栋楼，架构师说好吧，我来帮你看看是做成砖木结构还是 框架结构，房型怎么设计，水电气怎么布局，预算多少，然后程序员上阵，按照图纸把楼建起来。运营是大楼的物业管理，负责营运大楼。
软件开发越来越成为传统行业（即便在互联网企 业），一个成熟的软件团队内部自然会分化出这些角色，各展所长。但非常不同的是，建筑工人很少能自发成长为建筑师，后者都是科班出身，因为建筑学科已经高 度发达，需要掌握结构力学，美学等技术，现在软件行业还没有这么高的成熟度，程序员和架构师接受的都是一样的计算机教育，所以程序员可以自学升级到架构 师，走一条不同的升级打怪路线。
那么，架构师是什么人呢？
按所工作的不同软件层分，有网络架构，系统架构，数据架构，业务架构，应用架构，平台架构。
按所解决的问题领域分，有电商架构，支付架构，搜索架构，安全架构，性能架构，游戏架构，多媒体架构，等等等。
按其工作的深度来分，有集成架构，业务架构，模块架构，框架架构，中间件架构，软件架构，引擎架构，服务器架构，甚至编程语言架构。
是不是太乱了？好比在设计师的世界观里一切东西都需要设计。软件也需要精心设计，在优秀的程序员眼里，每一行代码都需要架构！都体现了架构。
为了解决问题，程序员自然需要架构，他们中的佼佼者被冠以架构师的名号，获得了一定的话语权，逐步成为一个职业分工，我想，这就是架构师的本来面目。
成为架构师，需要经验和眼界
老码农分为两种：游击队和板凳王
坐穿板凳有利于积累经验，而不利于开拓眼界
游遍四海有利于开拓眼界，而不利于积累经验
码农的生活是高压的，唯有热情可以驱使你一边吃着苹果，一边又去摘梨
然而，又有多少热情没有随时间而冷却呢？
Java进阶之路——从初级程序员到架构师，从小工到专家- https://zhuanlan.zhihu.com/p/27991030
对分布式存储，云计算及并行编程有一定研究。
搜索、推荐、广告等.企业级架构-跨越业务和 IT 之间的鸿沟.
职业道路不用太严肃，要干点好玩的事情，走不一样的路。
有多年NIO领域的设计、开发经验，对HTTP、TCP长连接技术有深入研究与领悟。
成为Java架构师必须要懂的知识- http://www.jianshu.com/p/925d9aa27be4
Java架构师要掌握哪些技术：一个是基础技术，另一个就是组织能力和提出解决方案能力了。
熟练使用各种框架，并知道它们实现的原理。Jvm虚拟机原理、调优操作，懂得jvm能让你写出性能更好的代码；池技术也是要掌握的，对象池、连接池、线程池都要会；Java反射技术，写框架必备的技术；Java各种集合对象的实现原理，了解这些可以让你在解决问题时选择合适的数据结构，高效地解决问题，写出代码；nio，注意“直接内存”的特点，使用场景。
熟练使用各种数据结构和算法，数组、哈希、链表、排序树等等都是；熟练使用Linux操作系统，也是必备的；熟悉各种协议，比如tcp协议，创建连接三次握手和断开连接四次握手的整个过程，不了解就没法对高并发网络应用做优化，http协议，session和cookie的生命周期与关联；熟悉系统集群、负载均衡、反向代理、动静分离，网站静态化；懂得分布式存储系统nfs，fastdfs，tfs，Hadoop了解他们的优缺点，适用场景，以及分布式缓存技术memcached，redis，提高系统性能必备.
一个软件架构师首要的和最重要的是他的远见。如果一个架构师拥有一些软件开发经验，那会更好，但大多时候，他们面对的是一个多语言的复杂环境。在第一行代码开始编写之前，架构师需要制定出业务需求如何转变成解决方案。这不仅仅需要业务环境的相关知识，从业务操作到客户环境，他还需要向公司上级勾画出一个令人信服的系统。如果有些问题不事先考虑，如扩展性，访问延迟问题，安全问题，系统开始开发时就会忽略这些。而资深程序员了解自己的团队，了解他们的能力。资深程序员知道如何管理工作进度，确保开发中的软件如何实现架构设计的目标。
架构要在理想和现实之间折中，保证架构的设计实用可行“接地气”，且又不过于“山寨”。具体总结为以下几点：
1. 要端到端地审视系统
因为无论在课本教学还是文章介绍中，讲解分析往往只是集中在一个系统的某一个小块地方，会加以简化与假设。但在现实中，系统则应该从端到端来处理，因此用这个模式来考虑问题，会得到一个比较合适的结果。否则可能会只看到局部，而丢掉全局的把控。谷歌的Jeff Dean也曾阐述过这一问题，强调要理解整个系统是如何串在一起的。
2. 对复杂性的理解和控制
因为只要是一个系统，到最后都会变得相当复杂，有各种原因导致它越来越复杂。对此我有一些经验，比如尽量把复杂性控制在一个地方，然后再通过一些分层次、模块之类的方法来将其隔离开来。我觉得对于做架构来说，很重要的一个工作就是对复杂性的控制，因为所有的系统到最后如果崩溃的话，基本上都是因为复杂性失控导致的。
3. 关注分布式
目前，所有的系统基本上都是分布式的，所以在设计系统时基本上都是以分布式为先，应该假设这个系统就是分布的。分布式代表什么？比如说一个请求可能会失败，你要做好对失败的处理，一个请求可能会不在你期望的时间内返回，会有一些超时的设计，可能涉及资源竞争。总而言之，各种在单机和单个程序内不会发生的错误，在这个产品里面都会出现，所以在设计的时候，一定要把这些因素考虑在内。
4. 性能
虽然Donald Knuth曾说过一句颇有名的话，就是“所有未成熟的性能优化是所有罪恶的根源”，意思是过早地做优化对整个系统是不利的。但是，还有一点我觉得可能没有说太清楚。所有的系统设计其实都应该有一些性能的考虑在内。虽然说不要过早做优化，但是应该定好几个标线。与此相关的还有Jeff Dean在一个PPT里列出来的：你应该对各个硬件和软件的各种延迟、各种吞吐量，有一些量化的理解，无论是硬盘、SSD、内存，还是CPU Cache，都应当有一个量级上的理解，以此保证你对这个性能的预估不会差得太离谱。因为如果架构开始出错，性能设计存在瓶颈，最后将极难推广。
5. 技术以外的其他因素
其实在我看来，架构是几个因素的综合考虑，包括：
技术，也就是目前有哪些技术可以用；
人员分配，你现在有哪些技术人员可以用。因为不同的工程师可能使用的技术不一样，举例来说，有些热门语言，比如Erlang VM上的Elixir，还有Spark、Scala等的适用人群和像是Python、PHP，或者Golang、C++等语言是不一样的。
产品，不同的产品对人和技术的要求可能也不一样；
时间表，你打算何时发布你的产品？
架构需要从这几个角度全面考虑，找到一个折中的点，也就是可行的位置。有时在这几点受限的情况下，可能是很难找到这个各方面都满意的平衡点。我认为架构师需要从这些因素排选，比如说某产品不行，就要砍掉一些功能；这些人员、这些技术不合适，可能就需要换技术或人；时间表如果满足不了就往后延迟——这是一个动态的过程，通过调整这几个因素来寻求平衡。
程序员更多是考虑一个局部的问题，而架构师可能更侧重全局考量。程序员眼中更倾向于一个点化的世界，可以有很多假设，但架构师往往不能有那么多假设，他需要根据实际情况来考虑问题，包括所掌握的人力资源、技术限制、时间安排等——在这些因素的约束下，选择将受限，一切也不再那么理想化。
另外一方面，架构师对知识了解的广度和深度，可能比程序员要高一些。因为架构师的某些决策，有时甚至会对他人的最终结果产生影响。如果程序员写了很多代码，那个代码却无法做出产品，这无疑是时间的浪费，而我觉得在这一方面，架构师应该承担更多责任。
最后，架构师需要跳出技术——这是我想要给大家分享的一个建议，即不完全只看技术，而是要综合考量包括技术和技术以外的因素，将其想象成一个类似于数学优化的问题。换一个角度来说，就是给你一些材料比如技术和人员，你要获得结果包括产品和团队，而这个时候很多情况是不理想的、有限制的，包括预算和时间的限制，所以你要思考如何灵活处理这个问题，包括调整各种输入、限制，甚至是输出，从而获得更优或者至少是可行的方案。架构师的世界，不仅仅是技术，通常囊括人员、沟通、产品等各种因素。把这些因素都考虑进去，才是一个完整的架构设计。
个人觉得架构师需要具有以下几特点：
1.知识广度：需要知道主流技术为什么诞生，能解决什么问题？如果同一种业务用不用的技术来实现，会有什么哪些优缺点？比如：流行的ORM框架Mybatis 和 hibernate ，他们之间的优缺点是什么？要有清晰的认识会能在技术造型时做出正确的决定。
2.抽象能力：对业务和技术进行抽象。业务抽象就是对需求进行分析后，能够建立完美的实体类以及他们之间的联系。技术抽象是对整体架构进行一个分层，各层之间的交互。这至关重要，如果技术抽象能力不足，这会导致整个系统的架构不灵活，难以维护和扩展。
3.知识的深度：至少是某个领域的专家，比如消息队列，activeMQ熟悉其源码，知道其实现。
4.优秀的学习能力：对新的技术和前沿性的技术进行学习，使用它来解决工作中的业务问题。
那么你该如何去做呢?我觉得可以从以下几个步骤开始：
1: 扎实的JAVA 基础，Think in java上介绍的内容都能理解，做到这一步恭喜成为了程序员。
2：熟练使用主流框架，如：mybatis，spring 等。
3：研究过至少一种以web框架的源码，如spring mvc ，struts 等。
4：架构过或者参与过高并发系统设计，知道如何应对突发情况。
5：对自己所处的业务能够根据自己的知识维度，提出优化建议或者预测其风险点。
Java 工程化、高性能及分布式、高性能、深入浅出。性能调优、Spring，MyBatis，Netty 源码分析和大数据等
