最近内卷严重，一直有人问，怎么才能成长成为一名真正的软件架构师，我沉思良久。
回首看从业20年所走过的路，从技术小白一步一步成长起来，做了十多年的架构师和首席架构师，做CTO也六七年了，略有一些心得和感悟。
只是“软件架构师成长之路”，这个话题太大，涉及到方方面面，只能抓大放小，说一说主干的路，难免挂一漏万，请各位海涵。
接下来我们就来具体聊聊每个阶段该如何去做，从实战的角度，讲讲做的方法，都是多年经验总结，或许看上去没有那么高大上，但绝对实用。
从几十万的小项目到数千万的大项目，都可以用得上。
先来聊聊 架构师该如何做需求分析
前面已经讲述了如何做需求分析，通过准确、全面、深入的需求分析，我们搞清楚了到底要做什么，形成了可落地的业务架构，以及完整的功能点列表。
接下来，我们就要来进行架构设计了
架构设计是一个软件从无到有的过程，不是一蹴而就的，我们先来看看高层架构设计。
前面讲到了架构师在高层架构设计阶段要做的事情，以及基本的方法。
接下来具体地看看如何把设计落地：首当其冲的就是要确定系统边界
下面就来聊一聊确定系统边界要做什么，以及如何确定系统边界。
前面已经讲到了系统高层架构设计落地的第一步，确定系统边界。
接下来具体地看看系统高层架构设计落地的第二步：如何进行服务拆分，这也是很多新手架构师犯怵的地方，一起来看看吧
一：服务是什么
最近在一位老朋友的要求下，帮他表弟做了个跳槽加薪的规划。
我很少做这样的规划，因为通常都是费力不讨好的，你做了规划，他也不一定按照你说的去做，或者是很难坚持去做到，最后就往往演变成埋怨，里外不是人。
但是朋友再三要求，只好破个戒，大家也帮我参谋一下，谢谢啦！
前面已经讲到了高层架构设计落地的第二步：如何进行服务拆分。
接下来聊聊AKF扩展立方体，以及模块划分的一些基本原则。
AKF扩展立方体形象地描述了一系列用于系统扩展的方法，它以AKF公司合伙人的名称命名，形如：
前面已经聊到了如何做高层架构设计，并开始让设计落地，去划分了系统边界，进行了服务和模块的拆分。
也就是系统的整体轮廓已经有了，接下来，就该来做整体的技术架构设计了。
其实做架构设计一点都不神秘，都是有章可循，有方法可依的。
所谓资源估算是指：对软件系统上线运行时，为了完成预定的目标，而需要的服务器资源、存储资源、CPU、内存、网络带宽等资源进行预估。
一般要预估正常使用情况、高峰使用情况、未来发展使用的情况等。
通常需要估算1-3年的情况，要求高一些的会预估到5年的情况。
前面已经把用于功能开发的 整体技术架构基本搭建好了，感觉已经可以落地使用了。
但是，仍然会有很多没有考虑全面的地方，比如缓存和异步消息的架构，这两个基本上是 目前 做实际应用的标配了
因此在高层架构设计阶段， 同样要对这样通用的、或者是公共的架构进行架构设计。
前面已经把用于功能开发的 整体技术架构基本搭建好了，感觉已经可以落地使用了。
在高层架构设计阶段， 同样要对这样通用的、或者是公共的架构进行架构设计
我们接下来聊一聊如何确定异步消息系统MQ架构的话题。
通过前面的文章，已经把用于功能开发的整体技术架构 基本搭建好了， 缓存和异步消息架构也确定好了，是不是整体技术架构就可以了呢？
很显然不是，仍然有很多缺失的部分，比如对于高并发和海量数据的处理，这两个基本上也算是目前实际应用当中的标配了，
因此在高层架构设计阶段， 同样要对这样通用的功能 进行架构和处理方案的设计。
接下来看看海量数据问题的处理思路
注意是海量数据，是业务功能处理所涉及的数据量较大，不是指大数据的分析处理。
通俗地说，就是数据很多，数据量很大，记录数一般在千万级或者亿级甚至更多；存储在一个或多个服务器上；存储体量一般在TB级甚至PB级以上。
通过前面的文章，已经把用于功能开发的整体技术架构 搭建好了， 缓存和异步消息架构 也确定好了。
接下来看看系统安全方面的架构设计
首先，需要分析哪些方面有安全威胁？然后才能针对性地做安全方面的架构设计，给出具体的解决方案
通过前面的文章，已经把高层架构设计所涉及到的各个部分基本讲清楚了。
接下来看看概要设计阶段要做什么以及如何做。
概要设计阶段要做的事情很多，把它总结梳理了一下，分成了如下十个大的方面，像写设计文档这些，都不算在内。
前面，已经把概要设计阶段要完成的任务和方法做了基本的讲述
接下来看看如何做基础框架设计，在讲之前，我们先来统一一下对软件框架的认识；然后去理解框架和设计模式的关系，为后续的讲解做好准备。
框架是能完成一定功能的半成品软件
接下来看看如何做基础框架设计，聊聊要做些什么、以及如何做基础框架设计；然后再看看使用基础框架功能的基本方式。
一：基础框架要实现的功能的来源
1：持续积累的通用功能、公共功能
在上一篇文章中，概要讲述了架构师在实际工作中到底要做些什么，以及要匹配具备什么样的能力。
接下来，我们逐步展开来讲述，从零开始，逐步培养架构设计思维、讲解架构设计技术、掌握架构设计方法、循序渐进进行架构设计实战训练，从根本上提升能力，早日成长成为真正的架构师。
先来聊聊两个基本的概念：什么是架构，以及架构的分类。
前面聊了这么多有关架构和架构设计的内容，统一的主题是架构师之路
架构师是一个大家耳熟能详的词。可是，如果有人问，什么是架构师？估计很多人就回答不上来了。
下面就来详细聊聊什么是架构师，以及对架构师的一些基本认识。
程序员，曾经被视为“金领”的工作，划为人“傻”钱多的一类，也曾是不少青春美少女心目中理想的人生伴侣。
然而世事变幻无常，程序员这个曾让人羡慕的职业，已“跌落神坛”，沦为代码民工，搬砖的存在，
更被官方定义为“新型农民工”，从此不再是自嘲，而是有了官方实锤的背书。
架构设计是一个大家耳熟能详的词，基本都烂大街了。
可是，到底什么是架构设计呢？估计很多人就回答不上来了。
下面就来详细聊聊什么是架构设计，以及对架构设计的一些基本认识。
到目前为止，请求已经能交给我们的处理器进行处理了，接下来的事情是要进行收集数据啦，接下来我们看看我们能从请求中收集到哪些数据
1、@RequestParam绑定单个请求参数值； 2、@PathVariable绑定URI模板变量值； 3、@CookieValue绑定Cookie数据值 4、@RequestHeader绑定请求头数据； 5、@ModelValue绑定参数到命令对象； 6、@SessionAttributes绑定命令对象到session； 7、@RequestBody绑定请求的内容区数据并能进行自动类型转换等。 8、@RequestPart绑定“multipart/data”数据，除了能绑定@RequestParam能做到的请求参数外，还能绑定上传的文件等。
@RequestParam用于将请求参数区数据映射到功能处理方法的参数上。 public String requestparam1(@RequestParam String username) 请求中包含username参数（如/requestparam1?username=zhang），则自动传入。 此处要特别注意：右击项目，选择“属性”，打开“属性对话框”，选择“Java Compiler”然后再打开的选项卡将“Add variable attributes to generated class files”取消勾选，意思是不将局部变量信息添加到类文件中
Spring4新特性——泛型限定式依赖注入 Spring4新特性——核心容器的其他改进 Spring4新特性——Web开发的增强 Spring 4.0已经发布RELEASE版本，不仅支持Java8，而且向下兼容到JavaSE6/JavaEE6，并移出了相关废弃类，新添加如Java8的支持、Groovy式Bean定义DSL、对核心容器进行增强、对Web框架的增强、Websocket模块的实现、测试的增强等。其中两个我一直想要的增强就是：支持泛型依赖注入、对cglib类代理不再要求必须有空参构造器了
Spring4新特性——泛型限定式依赖注入 Spring4新特性——核心容器的其他改进 Spring4新特性——Web开发的增强 接上一篇《Spring4新特性——泛型限定式依赖注入》，接下来我们看看Spring4的其他改进。 1、Map依赖注入： @Autowired private Map
从Spring4开始，Spring以Servlet3为进行开发，如果用Spring MVC 测试框架的话需要指定Servlet3兼容的jar包（因为其Mock的对象都是基于Servlet3的）。另外为了方便Rest开发，通过新的@RestController指定在控制器上，这样就不需要在每个@RequestMapping方法上加 @ResponseBody了。而且添加了一个AsyncRestTemplate ，支持REST客户端的异步无阻塞支持。
在之前的《跟我学SpringMVC》中的《第七章 注解式控制器的数据验证、类型转换及格式化》中已经介绍过SpringMVC集成Bean Validation 1.0（JSR-303），目前Bean Validation最新版本是Bean Validation 1.1（JSR-349），新特性可以到官网查看，笔者最喜欢的两个特性是：跨参数验证（比如密码和确认密码的验证）和支持在消息中使用EL表达式，其他的还有如方法参数/返回值验证、CDI和依赖注入、分组转换等。对于方法参数/返回值验证，大家可以参阅《Spring3.1 对Bean Validation规范的新支持(方法级别验证) 》。
Spring4新特性——泛型限定式依赖注入 Spring4新特性——核心容器的其他改进 Spring4新特性——Web开发的增强 Spring4新特性——集成Bean Validation 1.1(JSR-349)到SpringMVC Spring4新特性——Groovy Bean定义DSL Spring4新特性——更好的Java泛型操作API 随着泛型用的越来越多，获取泛型实际类型信息的需求也会出现，如果用原生API，需要很多步操作才能获取到泛型，比如： ParameterizedType parameterizedType = (ParameterizedType) ABService.class.getGenericInterfaces()[0]; Type genericType = parameterizedType.getActualTypeArguments()[1];
Spring4新特性——泛型限定式依赖注入 Spring4新特性——核心容器的其他改进 Spring4新特性——Web开发的增强 Spring4新特性——集成Bean Validation 1.1(JSR-349)到SpringMVC Spring4新特性——Groovy Bean定义DSL Spring4新特性——更好的Java泛型操作API Spring4新特性——JSR310日期API的支持 Spring4新特性——注解、脚本、任务、MVC等其他特性改进 一、注解方面的改进 spring4对注解API和ApplicationContext获取注解Bean做了一点改进。 获取注解的注解，如@Service是被@Compent注解的注解，可以通过如下方式获取@Componet注解实例
之前有一篇《5分钟构建spring web mvc REST风格HelloWorld》介绍了普通方式开发spring web mvc web service。接下来看看使用spring boot如何快速构建一个。 Spring Boot使我们更容易去创建基于Spring的独立和产品级的可以”即时运行“的应用和服务。支持约定大于配置，目的是尽可能快地构建和运行Spring应用。
场景： 1、首先登录成功后访问正常页面没有问题的； 2、接着访问一个不存在的页面，即跳到相应的404页面，假设我的页面是jsp的； 3、再刷新一下就会又跳到登录页面。 场景分析： 1、首先登录成功，假设JSESSIONID=e688f231-c0f0-4757-b85b-9ff1e62221b3； 2、接着访问一个不存在的页面，提交的JSESSIONID=e688f231-c0f0-4757-b85b-9ff1e62221b3；即提交的JSESSIONID和登录成功的一样；没什么问题；
上一篇《Spring MVC测试框架详解——服务端测试》已经介绍了服务端测试，接下来再看看如果测试Rest客户端，对于客户端测试以前经常使用的方法是启动一个内嵌的jetty/tomcat容器，然后发送真实的请求到相应的控制器；这种方式的缺点就是速度慢；自Spring 3.2开始提供了对RestTemplate的模拟服务器测试方式，也就是说使用RestTemplate测试时无须启动服务器，而是模拟一个服务器进行测试，这样的话速度是非常快的。
请求映射 处理器定义好了，那接下来我们应该定义功能处理方法，接收用户请求处理并选择视图进行渲染。 URL路径映射：使用URL映射请求到处理器的功能处理方法； 请求方法映射限定：如限定功能处理方法只处理GET请求； 请求参数映射限定：如限定只处理包含“abc”请求参数的请求； 请求头映射限定：如限定只处理“Accept=application/json”的请求。 接下来看看具体如何映射吧。 6.5.1、URL路径映射 6.5.1.1、普通URL路径映射 @RequestMapping(value={"/test1", "/user/create"})：多个URL路径可以映射到同一个处理器的功能处理方法。 6.5.1.2、URI模板模式映射 @RequestMapping(value="/users/{userId}")：{×××}占位符， 请求的URL可以是 “/users/123456”或
①客户端—发送请求—服务器：客户端通过请求头Content-Type指定内容体的媒体类型（即客户端此时是生产者），服务器根据Content-Type消费内容体数据（即服务器此时是消费者）； ②服务器—发送请求—客户端：服务器生产响应头Content-Type指定的响应体数据（即服务器此时是生产者），客户端根据Content-Type消费内容体数据（即客户端此时是消费者）。
处理器拦截器简介 Spring Web MVC的处理器拦截器（如无特殊说明，下文所说的拦截器即处理器拦截器）类似于Servlet开发中的过滤器Filter，用于对处理器进行预处理和后处理。 5.1.1、常见应用场景 1、日志记录：记录请求信息的日志，以便进行信息监控、信息统计、计算PV（Page View）等。 2、权限检查：如登录检测，进入处理器检测检测是否登录，如果没有直接返回到登录页面； 3、性能监控：有时候系统在某段时间莫名其妙的慢，可以通过拦截器在进入处理器之前记录开始时间，在处理完后记录结束时间，从而得到该请求的处理时间（如果有反向代理，如apache可以自动记录）； 4、通用行为：读取cookie得到用户信息并将用户对象放入请求，从而方便后续流程使用，还有如提取Locale、Theme信息等，只要是多个处理器都需要的即可使用拦截器实现。
load Average 1.1：什么是Load？什么是Load Average? Load 就是对计算机干活多少的度量（WikiPedia：the system Load is a measure of the amount of work that a compute system is doing） 简单的说是进程队列的长度。Load Average 就是一段时间（1分钟、5分钟、15分钟）内平均Load。【参考文章：unix Load Average Part1：How It Works】
命令行查看Memcached运行状态 很多时候需要监控服务器上的Memcached运行情况，比如缓存的查询次数，命中率之类的。但找到的 那个memcached-tool是linux下用perl写的，我也没试过windows能不能用。后来发现个简单的办法 可以做到，就是使用Telnet。 首先登录到服务器，然后在cmd命令行中键入 telnet 127.0.0.1 11211
mysql由5.1版本开始支持分区,虽然还是 not production-ready,但也是值得期待的一个新特性,关于分区,mysql的手册已经讲得比较详细,以下内容只是从手册的摘抄: 分区的一些优点： 1)与单个磁盘或文件系统分区相比，可以存储更多的数据。 2)对于那些已经失去保存意义的数据，通常可以通过删除与那些数据有关的分区，很容易地删除那些数据。相反地，在某些情况下，添加新数据的过程又可以通过为那些新数据专门增加一个新的分区来很方便地实现。 3)一些查询可以得到极大的优化，这主要是借助于满足一个给定WHERE 语句的数据可以只保存在一个或多个分区内，这样在查找时就不用查找其他剩余的分区。因为分区可以在创建了分区表后进行修改，所以在第一次配置分区方案时还不曾这么做时，可以重新组织数据，来提高那些常用查询的效率。
、首先创建数据绑定器，在此此会创建ServletRequestDataBinder类的对象，并设置messageCodesResolver（错误码解析器）； 2、提供第一个扩展点，初始化数据绑定器，在此处我们可以覆盖该方法注册自定义的PropertyEditor（请求参数——>命令对象属性的转换）； 3、进行数据绑定，即请求参数——>命令对象的绑定； 4、提供第二个扩展点，数据绑定完成后的扩展点，此处可以实现一些自定义的绑定动作； 5、验证器对象的验证，验证器通过validators注入，如果验证失败，需要把错误信息放入Errors（此处使用BindException实现）；
命令控制器通用基类，提供了以下功能支持： 1、数据绑定：请求参数绑定到一个command object（命令对象，非GoF里的命令设计模式），这里的命令对象是指绑定请求参数的任何POJO对象； commandClass：表示命令对象实现类，如UserModel； commandName：表示放入请求的命令对象名字（默认command），request.setAttribute(commandName, commandObject); 2、验证功能：提供Validator注册功能，注册的验证器会验证命令对象属性数据是否合法； validators：通过该属性注入验证器，验证器用来验证命令对象属性是否合法； 该抽象类没有没有提供流程功能，只是提供了一些公共的功能，实际使用时需要使用它的子类
Spring Web MVC 是由若干组件组成的，这些组件相互独立又相互协调工作共同完成 Spring Web MVC 工作流。每个组件都有清晰的接口定义，接口后面都有一个设计良好的类实现体系结构，清晰的抽象出公用的逻辑并且实现在通用的抽象类里，同时提供常用的具体实现类。 进而实现一个清晰的，高可扩展的，可插拔的 Web MVC 体系结构。 下面我们介绍这些典型的组件，组件的功能以及组件所定义的接口。 派遣器处理器 Servlet 对象 (Dispatcher Servlet) 派遣器处理器 Servlet 对象 (Dispatcher Servlet) 是 Spring Web MVC 中最核心组件，它是一个实现类而并不是一个接口。
Spring是一个轻量级 J2EE框架。它可以运行在任何一个 Web容器上。事实上， Spring的入口点就是实现或者继承了 Web容器规范中的 Servlet, 监听器 (Listener)和过滤器 (Filter)。这一章我们将详细讨论 Spring Web MVC架构的具体实现。 1.1 DispatcherServlet的实现 DispatcherServlet是一个经过多个层次最终继承自 Servlet规范中的 HttpServlet, 进而实现 Servlet规范中定义的Servlet接口。这些继承和实现组成了一个复杂的树形结构，在树形结构中的每个层次的类完成一个特定的初始化功能，服务功能或者清理资源的功能，每个层次的类之间分工合理，易于扩展
作为总控制器的派遣器Servlet将得到的处理器传递给支持此处理器的处理器适配器，处理器适配器然后调用处理器中适当的处理器方法，最后返回处理结果给派遣器Serlvet。 处理器架构中并没有简单的处理器接口定义，任何一个对象类型都可以成为处理器，每个类型的处理器都有一个对应的处理器适配器，用于将HTTP请求适配给一定类型的处理器。 处理器根据类型分为简单控制器，注解控制器和HTTP请求处理器。我们在讨论基于流程的实现的小节中，已经对每种类型中的典型实现类进行了剖析。下面我们就对不同类型的处理器进行详细的剖析。
上一小结中，我们剖析了简单控制器的实现体系结构。事实上，自从Spring 2.5引进了注解方法控制器, 已经不推荐使用简单控制器的实现体系结构中的基于Form的实现类。 注解控制器是通过在一个简单的Java对象上声明具有元信息的注解来实现的。所以，注解控制器并没有接口，抽象类或者实体类的实现体系结构。然而，声明在简单的Java对象上的注解则扮演着至关重要的角色
HTTP请求处理器是用来实现基于HTTP请求的远程调用的处理器。在前面章节基于流程的分析中，我们已经对典型的HTTP请求处理器进行了详细的分析和代码注释。事实上，除了HTTP调用服务导出器(HttpInvokerServiceExporter)的实现，还有更多的基于HTTP请求的远程调用的实现
除了HTTP调用服务导出器以外，还有两个远程调用的实现类，他们是Hessian服务导出器和Burlap服务导出器，他们的实现流程和HTTP调用服务导出器的实现流程非常类似，区别在于他们并没有在HTTP协议上传递远程调用对象和远程调用对象结果的序列化数据，而是使用他们专用的在HTTP协议上传输的数据格式来实现远程调用
从前面的章节分析中得知，处理器映射机制支持处理器拦截器功能。处理器拦截器应用一定的功能在满足一定条件的请求上。 处理器拦截器必须实现HandlerInterceptor接口，它定义了三个方法如下， preHandle() 任何处理器调用之前调用的方法。它返回一个布尔值，如果返回真，则继续调用处理器链的其他处理器或者拦截器，如果返回假，则停止调用处理器链的其他处理器或者拦截器，在这种情况下，它假设拦截器已经处理了HTTP请求，而且写入了HTTP响应。
上一节，深入的剖析了作为总控制器的派遣器Servlet如何通过处理器映射查找处理器，并且通过处理器适配器进行适配调用处理器实现的业务逻辑服务，进而返回逻辑视图名和模型数据对象。 这一节，我们将分析作为总控制器的派遣器Servlet如何解析视图和显示视图。这是Spring Web MVC流程中最后一个关键步骤。 由于视图显示技术的多样性，存在很多视图解析器和视图的实现，这一节我们将分析典型的视图解析器和视图显示的实现。他们是基于URL的视图解析器，然后，对于其他更多的视图解析器和视图的实现进行剖析
