IT架构师介绍-软件架构设计学习第一天（非原创）
文章大纲
一、架构师定义
二、架构师分类与具备能力
三、研发人员发展的技术路线
四、架构师知识体系
五、参考文章
一、架构师定义
什么是架构师，这个聊架构话题时永恒的问题。每个公司对架构师的定位也有所不同，因为不同公司所处的阶段，业务模式，应用场景也都不一样。对架构的要求也不一样。
在初创公司的野蛮生长阶段：业务场景和需求边界很难把握，有时候根本不需要架构师，产品需要快速迭代和变现，需求频繁更新，这个时候需要的是快速实现。当然如果公司成长以后，这个阶段就是欠下很多技术债，埋下很多坑，如果人员流动很频繁，后期系统维护成本是非常巨大的。
在公司成长稳定阶段：业务模式和应用场景边界都已经比较清晰，这个时候最需要架构师需要架构师能对线上业务进行模块划分，系统拆分重构，并做好相关高可用的措施，以保证系统的稳定，安全、高效地运行。
不同的行业，对架构师的要求也不同，比如电商业务和AI领域，从架构到业务场景，完全是两个物种。
在百度百科里面这么定义： 系统架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导任务。具体来说是一个确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员。主要着眼于系统的“技术实现”。因此架构师应该是特定的开发平台、语言、工具的大师，对常见应用场景能马上给出最恰当的解决方案，同时要对所属的开发团队有足够的了解，能够评估自己的团队实现特定的功能需求需要的代价。系统架构师负责设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单等。
架构师实际上就是软件的总体设计师。打个通俗的比方比如某个工程总设计师，类似三峡工程的总设计师。
架构师的形成一定是在实践中积累起来的，而并非上了几次培训班，读了几本书就可以成功的，架构师是在工程实践中培养出来的!
二、架构师分类与具备能力
1. 架构师分类
其实架构师就是个title，每个公司称呼都可能不一样，和架构概念一样
1.1 软件架构师
软件架构师是软件行业中一种新兴职业，工作职责是在一个软件项目开发过程中，将客户的需求转换为规范的开发计划及文本，并制定这个项目的总体架构，指导整个开发团队完成这个计划。主导系统全局分析设计和实施、负责软件构架和关键技术决策的人员，比如这些架构师的title可能是JAVA架构师、Python架构师、LAPM架构师等等。
1.2 解决方案架构师
与客户探讨业务需求，将业务、市场，与技术、产品结合起来，为客户提供解决他们需求的方案。比如阿里云针对大客户都有解决方案架构师。
1.3 系统架构师
也称应用架构师。最终确认和评估系统需求，并将业务转换为技术，为研发人员制订核心框架与技术规范 为研发工作澄清技术细节并扫清技术障碍 。服务器负载，可靠性，伸缩，扩展，数据库切分，缓存应用
平台架构师:这里的平台其实包括两个平台，一个是系统平台，也就是负责搭建多个系统整合的系统应用平台；另外一个其实是基础平台，是专门负责搭建基础技术平台；两者其 实区别蛮大，也经常容易被从业人员混乱。举个简单例子，金蝶有平台架构师一职，但是金蝶BOSS应用和金蝶中间件两者招聘的对象和技术要求是截然不同的。
1.4 业务架构师
业务架构其实已经开始脱离技术层面了，但是它要求架构师有跨越多系统的大局观，去整合和组织不同系统的技术平台与交互模式。其实这个职位的未来也就是CIO了。 主要内容：理解业务，梳理模型，设计模式，接口，数据交互。
1.5 网络架构师
过去，我们可能听的最多的是网络工程师。不错，一个优秀的网络架构师必须有足够的网络技术基底，并且它的关注点也是系统的基础架构。比如说如果搭建并优化集群环境，如果构建基于云计算的系统应用与部署等等。它对于像淘宝、腾讯这样的互联网公司是极其重要的。
1.6 移动架构师
移动互联网的迅猛发展横向和纵向都细分出了很多新的职责和岗位，移动架构师的职责和作用日益重要，既要整体和全局考虑整个前后端的软件系统架构，又要重点深入移动客户端的架构设计的方方面面，既要有跨平台思维，又要拿捏好原生和混合开发的尺度，另外移动应用的特点，导致移动架构师必须要比传统系统架构师更加注重非功能性的质量属性。
1.7 前端架构师
这也是移动互联网的迅猛发展而细分出来的新的职责和岗位，这里的前端特指网站开发中的前端，主要考虑前端呈现层的设计（HTML/CSS/JS/AJAX/RIA/…），跨浏览器设计等等。
1.8 大数据架构师
比如某些公司做大数据处理，需要理解业务，并通过大数据相关技术来实现。
2. 架构师需要具备能力
2.1 技术实力：每个好架构师都是好的程序员
总结：游泳教练，必定游泳水平好，因为这些都是实践性很强的工作。书上学来终觉浅，绝知此事要躬行。
这一点毋庸置疑，如果不是写过N年代码的优秀程序员，一定不是好的架构师。“架构师”这是一个听上去比较虚的职位，它的主要价值在于“落地”的过程中，而不是“指点江山”。eBay的架构师总结架构师在项目中的职责：
解决方案
产品团队要做一个产品，架构师要帮助团队把技术可行性，技术方案权衡取舍一一剖析清楚；
架构设计和技术实现步骤
技术方案权衡取舍出来了，架构师要设计整体的技术实现步骤，这个过程一定是和团队其他成员一起完成的，常见的实践是，1到2个核心成员出一个初稿，然后大家讨论完善；
编写核心模块
技术实现步骤出来了，架构师要和开发团队一起，进行编码，可能架构师不一定细究到任何细节，常见的实践是，系统最困难最核心最关键的部分往往由架构师亲自操刀；
部署上线和完善流程
系统初版实现了，架构师要和开发团队、测试团队、运维团队一起，完成各类测试，协助解决最困难的bug，和团队一同完成线上部署、并一同排除上线初期系统的故障；
在项目的过程中，架构师至少一半以上的时间是和开发团队一起进行的，好的架构师不能将实施细节抛之脑后，更直白一些，他要通过撰写代码的方式来指导团队其他成员理解和实现架构中的细节。
反面的例子是，项目失败后，架构师反馈“团队的技术能力不够”，团队反馈“这是一个一行代码也不会写的大忽悠”。
2.2 业务理解和抽象能力：驾驭概念的技能是最高潜力
总结：抽象能力是善于把实物概念化并归类。
业务理解
架构师需要理解业务，并转换为可被研发理解的实现方案，因此业务理解能力是架构师的必备技能。
通常来说一个资深的业务架构师，对业务有足够的敏感度和深入的认知和积累，能够清楚地知道自己的设计能给公司带来多大的业务影响，应该能大概预判业务未来的发展趋势，以便在系统的可扩展性上留好一定的空间，所以也会很自然的出现有些业务架构师做着做着就干脆转为PD类型的角色。
抽象能力
是通过对业务的理解转换为系统实现的模型，这显然也是重要的能力，抽象很多时候也承担了分解清楚多个团队的职责，分工清晰化。
“逻辑思维，抽象思维”比“编码的时间”对架构师而言更为重要，如果你不能让某个非IT人员明白某个概念在说什么，这个架构师注定也是失败的逻辑思维不用展开多说，程序员的代码都是逻辑，如果XXX就YYY，如果AAA就BBB，缺乏良好的逻辑思维能力基本不可能成为好的架构师，甚至好的程序员。
抽象思维又分两点，一个是将实在的事物概念化，一个是将模糊的感觉数量化。一个苹果，抽象为质量、大小、颜色、形状、味道等，这是概念化，是架构师的必备思维。至于质量、大小、颜色、形状、味道如何转变成数字来描述，这也是架构师必备的思维。
比如面对一个大型的B2C网站，能够迅速抽象为采购->运营->前台搜索->下单->履单这几大块，对系统分而治之，庖丁解牛，早已目无全牛。
有了上述两点，架构师能将一个“虚”的架构概念描述清楚。
2.3 设计能力
具有前瞻性的设计眼光，站在技术的山顶向前眺望
铁打的程序员，流水的技术。程序员的开发生涯可能长达几十年，但一门技术的平均寿命却不长。因此作为程序员们的技术领袖，架构师必须有 很好的技术前瞻性，要先于大家了解到最新的技术。
架构是过程，并非结果: 架构是架构师洞察内在结构、原则、规律与逻辑的过程，架构师要做到清晰理解系统，以及简洁描述，这是分析整合的能力。
一个架构师必须具备极强的分析能力，要做到根据产品宗旨和目标，分析清楚产品定位以及产品业务，再整合利用现有的技术领域，找出最佳方案，实现产品概念。
架构师与技术高手的区别在于，架构师不仅局限于如何调用、如何并发等架构细节（技术高手对这些也非常熟练），还跳出三界，考虑未来问题和潜在风险的应对之道。
一名合格的架构师设计出来的架构是要有前瞻性的，要为了将来的组织能力更上一个台阶而设计， 满足当下需求并能够适当扩展，是遵循架构设计的系统实现要关注的事情，系统是多样的，架构不是，系统是演化出来，架构不是。
要培养自己的技术前瞻性，首要是学好英语（不多届时了，希望未来最先进的技术都首先从国内诞生），看懂外文技术文章，能与业界专家沟通交流，学习别人的实践方案。
反面的例子是，成天将技术前言的名词挂在嘴边，大谈“云计算，SaaS”这些东西，天天吹水，而落不了地（有可能他自己也搞不清概念如何落地）。
技术前瞻性还提现在对新技术的选型上，哪些东西适合自己团队，哪些不适合。学习成本、维护成本、硬件成本、潜在风险等等都是架构师需要考 虑的。
架构师在自己所处的领域肯定了解颇深，未来本领域技术该如何发展，应该有自己的理解。也会对未来技术的发展有所期盼，有自己的见解。当然这属于比较发散的想法，个人有个人的目标。
2.4 技术深度
能透过问题看本质，解决问题和绕开问题
总结：透过问题看本质则是由虚到实，往深层次地挖掘
看到问题的本质，是架构师必须具备的素质。
例子1：菜鸟程序员的如此写php：
echo $_GET['username'];
大部分人知道这个出现安全隐患。一般人使用htmlspecialchars解决问题就可以了。但问题的本质是什么？可以从更深的层次去理解：
比如echo是如何执行的？在什么时候执行的？哪些字符可能导致安全问题？htmlspecialchars为什么能解决这个问题？它真的解决这个问题了么？
那么他将会一点一点的进步，逐渐成为一个合格的程序员。
再比如看到一段java代码，知道它在JVM如何执行；一个跨网络调用，知道数据是如何通过各种介质到达目标(操作系统内核/网卡端口/电磁介质等）。透过问题看本质使架构师能够敏锐地发现底层之真实，系统性端到端地思考问题，识别木桶的短板并解决之。
什么是本质？将世界万物理解为原子，将整个互联网理解成0和1，这倒的确是非常本质了，不过并不能解答任何问题。从问题看本质，实质上是一个从表层逐步深入的过程。在架构师面对一个用户需求时，这个“用户需求”是非常表层的——比如说，一个自动远程备份数据库的功能。而架构师的主要工作，就是把这样的“业务需求”翻译成“技术需求”。这个过程一方面需要通过抽象思维将用户需求提炼为启动、读取、存储、中断处理等模块，而另一方面则需要看到更深层次的网络、操作系统、硬件等方面，以及其可靠性、稳定性、适用性、安全性等问题。
架构师要有将“业务需求”转化为“技术需求”的能力，这是一个本质的挖掘。例如，业务层面看到的是一个“电子商务网站系统”，架构师看到的是一个多人在线，并发交易，需要保证数据一致性的站点、服务、数据系统，功能、性能、扩展性、维护性、安全性、可用性这些字眼会惯性的蹦到架构师的脑子里。
架构师之所以是架构师，他在庞大系统的面前，仍然能够敏锐发现其底层之真实，这就需要，他有多年多领域知识和经验的沉淀。
2.5 技术广度
要成为百科全书式的智者
总结：1、全面了解各个层面的知识。2、了解主流公司的系统设计，碰到实际问题，很快有多种方案可供评估。
首先，作为一名卓越的程序员，架构师肯定不欠缺开发方面的知识。从架构到方法论，从数据处理到安全监控。可以说IT开发层面上，架构师可以做到炉火纯青的地步。但是这仅仅是一名卓越程序员的能力级别，离架构师那还有很大的一段距离。
架构师作为一名技术领袖，需要通过散发知识的光芒来温暖开发团队，如果只一个领域内的知识烂熟于胸，那也仅仅是一名技术高手。要想更进一步，需要对APP层面、服务层面、数据层面均要了解（系统分层），要对研发、测试、运维、安全也要有所了解（职能），上要对接口，下要对原理（接口与实现）都有所了解，甚至，要在多个业务领域都有所涉猎。
有的程序员也会说，如果多学习跨领域、跨学科的东西，会不会成为什么都懂，但什么都不精的人？其实在这里的跨领域，并不是要求大家都成为每个领域的专家。最重要的是有一门敲门砖，学习的引子。如果开发一套金融系统，对于财务结算以及处理方法都不了解，那别说是胜任架构师的任务，连普通程序员的工作也不可能做好。假设大家工作一段时间后，对某领域很了解，但由于工作变动的缘故，到其他公司后，开发的领域完全不会。这里就要用到跨领域知识学习的能力了，需要大家样样都要知晓。
谈到跨领域学习，知识面广似乎是最好实现的目标，只要博览群书，加上高中之前各学科扎实的基础，相信大多数程序员本身就具备一定的跨领域学习的能力。但想成为真正的百科全书式的智者，恐怕不光是简单觉得眼熟就行。在条件允许的情况下，程序员其实可以去参加一些其他领域的专业考试。比如参加会计资格证的考试，抑或其他专业中较初级的考试。这样的经历，主要还是在于“以学促考”，通过一定的压力让自己能钻进去学习。
初级架构师所害怕的，是跳出自己的“独门绝技”，在一定程度上说，在一定深度之内成为一个“杂家”也没什么不好。
2.6 沟通能力
善于沟通的技术领袖
总结：沟通能力确保各方对架构达成共识，愿意采取行动
架构师必须参与项目开发全过程，包括确认需求、系统分解、架构设计、技术选型、制定技术规格说明、系统实现、集成测试和部署各阶段，在这一系列过程中，架构师会与各部门沟通交流。
一个产品会有多部门合作，架构师在其中的沟通极为重要，直接影响产品进度与质量。架构师不仅要与开发人员沟通，也要和项目经理、分析人员甚至用户沟通，来实现产品的各种可能性。
架构师和项目经理，对沟通能力的要求都很高，很多互联网公司甚至直接由架构师担任项目经理的角色。这两个角色其实还是有所偏重的，项目经理更倾向于与客户的交流，跨团队的协作与交流，架构师主要偏向技术团队内部的沟通与交流，纯技术上的沟通。
如何成为一名“善于沟通”的架构师呢？在目标清晰的前提下：
首先做到平和，不能将自己所在象牙塔上，颐指气使的发号施令，这样的态度必然遭恨，大家都是技术人员，只是分工不同，为何要受你的气呢？
其次，架构师要有一定的绘图能力。人对图形的理解远大于对文字的理解，一个层次图，一块小白板，几只笔，真的这么容易把问题描述清楚么？
做到人性化的沟通，需要我们在平时就进行培养。写出大部头的架构书，有的时候并没有用VISIO画出的简单架构图好理解。人对图形理解远远大于对文字的理解，直观简单的UML图可以极大的方便程序员理解架构师的意图。
其次，可以召开小范围的技术人员会议，大家一起来讨论，一起理解架构师真正的意图。甚至就是一块小白板，几支笔就能把问题摆清楚，讲明白，统一意见后的团队必然干劲十足，再不会出现互相推诿的情况。
架构师就相当于一支球队的主教练，如何将自己布置的战术交到执行的球员，也就是开发人员的脑袋里，是关乎胜利的关键。那么怎样才能成为一名能说会道的程序员呢？
在一般人的印象里，程序员都是一群略显呆滞，沟通能力不强的技术狂人。逻辑思维非同常人，但就是倒不出来。有些人通过找女朋友作为旁证，连经济适用男中的定义原型都是IT人士，月薪4000以上，不善言谈，最后娶一剩女为妻。看来我等程序员，真的只能被人如此定义了。虽说架构师技术层面上的东西与前例不可同日而语，但是也看到沟通能力上，程序员还有很大的发展空间。
2.7 系统性的思考
权衡利弊，只有合适没有喜欢
总结：系统性地思考：平衡取舍能力确保架构在现有资源约束下是最合理的，理想最终照进现实。
合格的架构师都是好的战略家，前瞻性眼光是他们起码的要求，而系统性的思考则是将这些前瞻性眼光落地的必备素质。
架构既看重前瞻，又看重落地，落不了地的架构只是空中楼阁，所以，如何将架构落地，考量的就是一名合格架构师的综合素质和系统思考的能力。
因为架构的规划和落地依附于现有的环境因素很多且不可重现，所以，合格的架构师要能够尽可能多的将对架构有过多权重影响的因素考量进来，然后做权衡，抓住重点因素，最后集中兵力重点突破。
比如，是采用传统的Monolith架构体系，还是时下风靡的微服务架构体系，你要能够从团队人员层次和能力，组织和公司的发展现状，时机等重点因素中做出权衡，你没法通过数据建模的手段去完成这个工作，你能依靠的，只有你的综合素质和系统思考能力：
从时机（Timing）上说，如果单个应用结点就可以满足业务发展需求，那么，就没有必要上微服务，否则反而凭空增加了整个交付链路的负担；
如果团队的成员能力还不足以支撑起微服务体系相关的所有工具化，服务化和平台化建设，那么微服务架构也不是最合适的方向；
如果公司业务还处在四处拼杀，生死未卜的时候，公司的现状也不会允许你去搞各种完善的基础性建设，活下来才是第一位的；
对于架构师来说，你要关注的不是“点”，而应该关注的是尽可能多的“点”，进而是连接点的线，到面，甚至到体。
三、研发人员发展的技术路线
1. 技术人员职位与等级介绍
2. 技术人员职责
2.1 高级程序员（管理自己）
（1）负责核心复杂功能的实现方案设计、编码实现
（2）负责疑难BUG分析诊断、攻关解决
2.2 研发经理（管理一个团队）
（1）团队任务管理：开发工作量评估、开发任务分配
（2）团队生产质量提升：代码审核、开发风险识别/报告/协调解决
（3）团队生产力提升：代码模板研发与推广、最佳实践规范总结与推广、自动化研发生产工具研发与推广
（4）团队专业力提升：招聘面试、新人指导、领导复盘总结改进
2.3 技术总监（管理多个团队经理）
（1）组建平台研发部，搭建公共技术平台，方便上面各条产品线开发。
（2）通过技术平台、通过高一层的职权，管理和协调各个产品线组。现在每个产品线都应该有合格的研发Leader和高级程序员了。
2.4 架构师（专注某个平台的技术架构规划）
需要分离管理族和专业族。整个研发团队可能已经超过100来人了，需要有人专注来做架构规划、设计、日常维护。不能让研发总监和研发Leader又做管理又做技术一股脑都扔给他们。
（1）架构分析：从功能性需求中识别出需要增加的非功能性需求，好满足性能、可扩展、解耦/集成、安全、可运维、高可用、易部署、易更新。并且识别完非功能型需求，还要做技术选型、技术架构风险识别、技术实现工作量评估
（2）架构设计与实现：非功能性模块的架构设计、接口设计、代码实现。所以需要的是有代码实现能力还要有架构思维的工程师，不需要画PPT的工程师
（3）业务架构设计与实现：需要对跨系统的接口进行识别、实现、维护，需要对能写成公共代码类库的进行分析、识别、接口设计、实现、变更维护。
（4）重构：架构师需要经常做Bug分析、非模板性和公共类库代码检查，以发现代码腐烂程度，以发现还有哪些代码没有做很好的架构与精心的代码设计。所以重构是经常性维护发生的，不是攒到某一刻动大手术，甚至推翻重做，那就不叫重构了。
2.5 CTO (软件产品和技术是统一管理的.是商业、产品、技术、管理、团队相平衡的综合统管)
（1）业绩达成：洞察客户需求，捕捉商业机会，规划技术产品，通过技术产品领导业务增长，有清晰的战略规划、主攻方向，带领团队实现组织目标
（2）前沿与平台：到这个研发规模规模级别了，一定要有专门的团队做技术应用创新探索和前沿技术预研。而且要和技术平台团队、应用研发团队形成很好的联动作用，让创新原型试点能够很平滑的融入商业平台再让应用研发线规模化的使用起来。大量的前沿探索都死在了内部，做完试点就停滞了，这就需要CTO做好整体的衔接推动工作。
（3）研发过程管理：站在全局立场来端到端改进业务流程，为业务增长提供方便
（4）组织与人才建设：公司文化和价值观的传承；研发专业族团队梯队建制建设、研发管理族团队梯队建制建设；创建创新激发机制，激发研发人创新向前发展，激发黑马人脱颖而出
3. 专业技术人员掌握知识体系
3.1 优秀程序员
成为优秀程序员，需要学好的知识：
（1）面向对象编程、UML画图、设计模式、代码重构
（2）常用ORM工具
（3）MVC,WCF,XMl, JQuery ，SQL以及性能优化
（4）FrameWork一些深入的知识
（5）高性能代码，比如静态化，MemCached等手段。
（6）最好也了解一些其他语言，比如Java，PHP等。
3.2 DBA
成为DBA，需要学好的知识：
（1）常用数据库，MSSQL、MySQL、Oracle，性能调优熟练，备份、负载均衡、集群、容灾熟练
（2）大数据量处理熟练
（3）各种数据库监控软件
3.3 运维
（1）各种Web负载均衡的硬件，比如F5，软件，比如Nginx等原理和配置
（2）反向代理加速，比如SquID等
（3）操作系统，Linux是必须懂的，各种好的工具都在Linux下。
（4）各种性能监控软件。
3.4 项目经理
（1）沟通和理解能力。
（2）该行业和本公司的业务逻辑。
（3）软件工程的知识。
（4）质量控制、进度控制、人员组织等。
四、架构师知识体系
1. 通用技能表
1.1 做事方法论：目标、方法、执行
我是谁
思维方式，不将就认真做事的人
如何做事
（1）整体把握，找到方法论（解决方案），
（2）思路：分而治之，优先排列，计划进行（排期完成）。
（3）及时沟通，反馈，勇于承担责任
（4）团队意识
成长
（1）和优秀的人在一起
（2）不断学习充电
完成定义
（1）了解基础原理，自测通过，及时跟踪反馈问题，文档更新
（2）做一个靠谱的人：凡事有交代，件件有着落，事事有回音。
1.2 思维结构
《金字塔原理》
《结构化思维》
《系统思维》
1.3 文档能力
熟练使用word、excel、ppt
1.4 协作
类似TAPD的在线协同平台
微信
例会
1.5 沟通能力
1.6 业务能力
熟悉公司和行业的一些业务逻辑
1.7 计划推进
质量控制、进度控制、人员组织、资源协调。具体能做到以下几点
（1）能够有效的组织各类资源，通过说服、协调等方式得到相关部门或人员的支持，以使计划顺利的推行下去；
（2）说服力、协调力、推动力、监控与反馈
1.8 项目管理能力
（1）架构评审
（2）代码规范
（3）代码 Review
（4）看板管理
（5）SCRUM
（6）敏捷开发
（7）极限编程（XP）
（8）结对编程
（9）FMEA管理模式
2. 专业技能表
2.1 基础知识
（1）计算基础
（2）计算机原理
（3）数据结构和常用算法
（4）操作系统:进程,线程,内存
（5）网络
（6）TCP/IP协议
（7）TCP/IP网络模型
（8）HTTP协议原理
（9）网络IO模型
（10）Socket网络编程
2.2 编程语言
比如：
（1）java基础类库
（2）JVM原理和调优
（3）并发处理
（4）多线程
（5）异常
（6）常用框架
（7）常用框架
（8）异常处理机制
2.3 程序设计
（1）高质量编码能力:
（2）重用性
（3）低耦合
（4）可扩展性
（5）可维护性
（6）高性能
（7）安全性高
（8）面向对象编程:
（9）MVC编程思想
（10）掌握建模语言和建模工具：UML
（11）面向对象思想
（12）设计模式:
（13）基础设计模式和设计原则:单一职责、开放封闭原则等.
（14）常用设计模式
（15）重构
2.4 研发能力
（1）熟悉瀑布模型：需求->需求分析->设计->开发->测试->上线->运维/运营
（2）调试和解决问题能力
（3）敏捷思想：快速迭代，任务细分，wiki更新
2.5 安全知识
（1）web安全：xss，sql注入，ddos攻击
（2）安全维度：漏洞，风险，事件
（3）https协议
2.6 操作系统知识
熟悉常见操作系统和比较其区别，比如Linux、Windows系统
2.7 运维能力
（1）监控
（2）持续集成：jenkins
（3）自动化运维工具：ansible，saltstack
（4）虚拟化：kvm,vm
（5）容器docker
（6）云技术openstack
（7）DevOps
2.8 数据库
（1）基础理论
（2）数据库设计的三大范式
（3）数据库原理
（4）数据库优化
（5）数据库引擎:
2.9 常用应用软件
Web server
（1）Nginx
（2）OpenResty
（3）Apache Httpd
（4）Tomcat:架构原理,调优方案
（5）Jetty
消息队列
（1）RabbitMQ
（2）RocketMQ
（3）ActiveMQ
（4）Kafka
（5）Redis 消息推送
（6）ZeroMQ
数据库中间件
（1）DBproxy
（2）Haproxy
软件负载均衡
（1）几种负载均衡算法： 轮询、权重、负载、最少连接、QoS
（2）DNS负载均衡
（3）Nginx
（4）LVS+Keepalived实现负载均衡
（5）HAProxy
（6）Haproxy+Keepalived+MySQL实现读均衡负载
2.10 性能
（1）性能优化方法论
（2）容量评估
（3）CDN 网络
（4）连接池
（5）性能调优
2.11 大数据知识
（1）Hadoop
（2）Storm
（3）Kafka Stream
2.12 工程化管理
（1）maven
（2）git
（3）svn
（4）jenkins
3. 架构基础知识
3.1 架构演进
（1）初始阶段：LAMP,部署在一台服务器
（2）应用服务器和数据服务器分离
（3）使用缓存改善性能
（4）使用集群改善并发
（5）数据库地读写分离
（6）使用反向代理和cdn加速
（7）使用分布式文件和分布式数据库
（8）业务拆分
（9）分布式服务
3.2 架构模式
（1）分层：横向分层：应用层，服务层，数据层
（2）分割：纵向分割：拆分功能和服务
（3）分布式
分布式应用和服务
分布式静态资源
分布式数据和存储
分布式计算
（4）集群：提高并发和可用性
（5）缓存：优化系统性能
（6）cdn
方向代理访问资源
本地缓存
分布式缓存
（7）异步：降低系统的耦合性
（8）提供系统的可用性
（9）加快响应速度
（10）冗余：冷备和热备，保证系统的可用性
（11）自动化：发布，测试，部署，监控，报警，失效转移，故障恢复
4. 架构核心要素
4.1 高性能：网站的灵魂
（1）性能测试
（2）前端优化
（3）应用优化
（4）数据库优化
4.2 可用性：保证服务器不宕机，一般通过冗余部署备份服务器来完成
（1）负载均衡
（2）数据备份
（3）自动发布
（4）灰度发布
（5）监控报警
4.3 伸缩性：建集群，是否快速应对大规模增长的流量，容易添加新的机器
（1）集群
（2）负载均衡
（3）缓存负载均衡
4.4 可扩展性：主要关注功能需求，应对业务的扩展，快速响应业务的变化
4.5安全性：网站的各种攻击，各种漏洞是否堵住，架构是否可以做到限流作用，防止ddos攻击
（1）xss攻击
（2）sql注入
（3）csr攻击
（4）web防火墙漏洞
（5）安全漏洞
（6）ssl
5. 架构设计能力
5.1 设计原则
（1）冗余设计
（2）回滚设计
（3）监控设计
（4）故障隔离
（5）可独立部署
（6）无状态设计
（7）成熟技术
（8）异步设计
（9）禁用设计
（10）服务可降级
（11）服务可限流
（12）水平扩展
5.2 接入层设计
（1）DNS轮询
（2）动静分离
（3）方向代理：LVS,NGINX
（4）CDN
（5）接入层安全：DNS劫持、限流，防刷。
5.3 应用层设计
（1）通信机制：RPC，MQ
（2）异步
（3）连接池
（4）配置中心
5.4 数据库层设计
（1）高可用数据库架构
（2）双主架构
（3）主从同步
（4）读写分离
（5）分表分库
