架构师的职责是什么？
进阶成为架构师是大多数java程序员们的梦想，架构师从广义上可分为软件架构师、系统架构师，软件架构师是程序员最容易突破、最可能进阶的一条职业发展路径，我这次主要分享软件架构师的相关知识点。一、架构师的定义架构师，是一个既需要掌控整体又要洞悉局部瓶颈，并依据具体的业务场景给出解决方案的团队领导型人物，他需要参与项目开发的全部过程，包括需求分析、架构设计、系统实现、集成、测试和部署各个阶段，负责在整个项目中对技术活动和技术说明进行指导和协调。
二、架构师的主要职责1、确认需求与拆分系统在项目开发过程中，架构师需要依据用户需求，将完整的系统拆分为子系统和组件，形成不同的逻辑层或服务，确定各层的接口、层与层相互之间的关系，对整个系统分层进行“纵向”分解，对同一逻辑层分块进行“横向”分解。2、技术选型通过对系统的一系列的分解，最终形成了软件的整体架构，依据整体架构需要进行技术选型。
3、制作技术规格说明在整个研发过程中始终保持与开发人员保持沟通，以保证开发者依照原定的架构意图去实现各项功能。三、架构师的综合能力程序员从初级、中级、高级再到架构师，是一个不断经验积累的过程，除了技术实力以外，其它软实力也不容忽视。备注：图表仅为抽样数据，不代表所有意见，供参考。我们来细说下排名前三的架构师必备能力：设计能力、技术能力、沟通能力。
1、 设计能力架构是架构师洞察内在结构、原则、规律与逻辑的过程，架构师要做到清晰理解系统、简洁描述，除此之外，一个架构师还必须具备极强的分析能力，要做到根据产品宗旨和目标，分析清楚产品定位、产品业务，再整合利用现有的技术领域，找出最佳方案，实现产品概念。2、 技术能力众所周知，架构师是团队中的技术权威，需要同时具备技术的深度和广度，至少精通1-2门技术，且技术广度的要求高于技术深度的要求，这样才能更加深入的理解架构相关工作原理，也可以拉近和技术团队的距离，并形成影响力。
3、 沟通能力架构师参与项目开发的全过程，包括确认需求、系统分解、架构设计、技术选型、制定技术规格说明、系统实现、集成测试和部署各阶段，与相关部门、技术团队关于各个环节的工作沟通在所难免，这就决定了架构师需要具备较强的沟通能力。以上，是架构师应具备的职责。以下，是程序员进阶成为架构师的系列专题资料，将关键词【架构】私信优知学院，即可秒领。
到底怎样的程序员能称为架构师？
作为一名从业多年的IT人，我来回答一下这个问题。首先，架构师是程序员发展的一个重要方向，也是IT行业中的重要岗位。一个软件产品的开发需要一系列角色的配合才能够完成，从一个产品的设计到最终的部署需要产品经理、策划、交互工程师、视觉工程师、架构师、产品经理、程序员、测试、运维工程师等一系列角色的配合。从研发的角度来说，程序员可以简单划分为两类，一类是设计，另一类是实现。
负责设计的程序员通常也就是所谓的研发级程序员，主要解决系统级问题，比如平台的研发、接口（API）的设计等工作，通常针对的是行业级问题。而负责实现的程序员通常是所谓的应用级程序员，通过接口来完成平台功能的调用从而实现具体的业务逻辑，工作的重点在于具体功能的实现，往往针对于具体的应用场景。技术领域的架构师也通常分为两个大类，一类是平台架构师，另一类是应用架构师。
平台架构师制定的是平台的研发策略和技术指标，通常要结合功能定位和行业定位来进行具体的设计。平台架构师通常是研发级程序员成长起来的，同时具备一定的行业前瞻性。比如James Gosling（Java创始人）和Linus Benedict Torvalds（Linux创始人）就是典型的平台架构师。通常所说的软件架构师大部分指的是应用架构师，针对于具体的应用场景给出软件产品的设计方案、技术选型和接口设计等，通常应用架构师需要对各种平台产品有较为清晰的了解，并能够紧跟技术发展趋势来不断优化设计方案。
另外，应用架构师需要具备一定的行业背景，对于方案的技术瓶颈有丰富的解决方案。应用架构师通常是应用级程序员成长起来的，往往具有多年的行业开发经验。我从事互联网行业多年，目前也在带计算机专业的研究生，主要的研究方向集中在大数据和人工智能领域，我会陆续写一些关于互联网技术方面的文章，感兴趣的朋友可以关注我，相信一定会有所收获。
架构师在做一个网站的架构时要做哪些工作（按顺序排列）？
我是一个假的架构师，真的程序员。现在所在的项目，是去年八九月份启动的，虽然不是一个网站，但是大部分工作都是类似的，那么我给大家介绍一下这半年我做了哪些工作。一般新建一个项目有两种背景：一种是没有系统，需要重新建立；一种是有老系统，但是因为种种原因，需要新建一个系统把老系统替换掉（或替换部分功能）；我们算是后者，老系统已经运行多年，主要工作是对外提供接口服务，现在服务的效率和抗压性都无法满足业务需求。
需求梳理需求，在开发之前一定要明确需求。因为是对老系统的改造，所以需求相对来说比较明确。梳理老系统有多少接口，压力比较大的接口有哪些，确定接口迁移的优先级。确定第一批迁移的接口之后，需要对接口的处理逻辑进行梳理，包括出参入参都是什么，对参数有哪些校验，出参的是从什么表的什么字段取得，查询条件是什么，是否对数据进行了加工、转移等处理。
主要是通过“扒代码”的手段，这一步很痛苦（程序员们都懂的）。压力预估因为是老改新，压力容易预估出来，我们主要关注的几个点：现有系统的数据量有多少，年增长的数据量是多少。多少系统在调用，大概服务器的数量是多少。平均每天的调用量，如果业务几种在某些时间段内，比如工作时间，那么就要估计出每小时的量大概是多少。
业务高峰期的时候，量有多少。架构设计其实我也是野路子出身，我在做这一步所做的工作有这些：整理项目的功能点，比如我们这个项目主要功能有：数据抽取、数据存储、数据加工、服务提供；这一步形成整体的功能架构。对每个大的功能点，评估需要使用的资源，拿数据加工为例：数据加工主要就是批处理，需要Tomcat部署Java程序，需要Redis做分布式锁和缓存，需要MongoDB做加工后的数据存储；这一步形成整体的方案规划。
继续详细的评估，根据前期统计的数据量，对MongoDB的部署进行评估：是否需要分片，如果分片的话，前期部署几个分片，容量申请多少；当这些评估都做完之后，就可以把一个一个的点汇总起来，就形成了物理部署架构。到了这一步，基本上技术架构图也就出来了。在设计过程中，还要和很多人进行沟通，比如DBA、比如领导。
开发到了开发阶段，我依然在。这时候，一边招人（招人有些晚了），一边搭框架；一边面试，一边写代码。最后开发人员招的差不多的时候，我从无到有，第一个接口基本上开发完成了...现在嘛，我依然在项目里面，沟通需求、设计、任务分配、写写代码、看看开发人员写的代码再给他们提提意见，如果别的项目组有设计或开发方面的问题，我也会帮忙处处主意；我总觉得我是个假的架构，真的程序员。
文章TAG：架构师