技术实力详解
理解评估技术实力的基本原则后，我们知道了需要解决的问题复杂度越高，技术实力就越高。在这个基础上，我把技术实力分为两大类 6 分类：
- 硬实力： 真正解决问题的能力，别人可以看出来的能力，技术实力按照“点、线、面、体”的 4 个分类逐层上升；
- 软实力： 比硬实力更厉害但也更虚的能力，简单来说，要想解决问题首先得发现问题，但很多时候问题并不是一目了然的，需要有一定的技术洞察力。软实力主要包括 2 个核心能力：发现问题、技术创新。
硬实力
我把技术硬实力分为四个等级：点、线、面、体，技术等级依次提升，解决的问题复杂度也越来越高，下面详细解释一下。
技术点
“点”就是某个具体的技术，用来解决某个具体的问题，例如使用 JDBC 从数据库读取数据，目的是解决数据掉电丢失的问题；使用 Java 多线程，目的是为了解决大量用户并发访问的吞吐量和时延问题。掌握了技术点，就可以开始基本的业务功能开发了。
技术线
“线”就是一系列相关的技术点组成，每个技术点都是为了解决某个问题。例如：
- 为了完成一个用户请求，开发框架首先要有路由 router 功能，路由到具体 Controller 后，Controller 进行业务逻辑处理，处理过程中可能会使用 JDBC 来读取数据，访问 Redis 读取缓存等，这一连串的技术每个都解决了一个问题点，串起来就完成了一个业务功能的处理过程。
- 为了定位一个线上 Java 服务器响应慢的问题，需要用到 tcpdump 抓包，使用 Java 工具查看 jvm 的状态，使用 mysql 命令行或者工具查看数据库状态，使用 explain 分析可疑 SQL 语句。
掌握了技术线，就可以完成某个业务功能的全流程设计和开发了。
技术面
“面”就是某一类相关技术线的综合。例如：
- Java 开发是一个技术面，包括多线程、JDBC、文件读写、JVM 调优、JVM 工具等多个技术线；
- 高性能开发是一个技术面，包括：数据库分库分表、缓存、多线程、HTTP 优化等；
- 数据库维护是一个技术面，包括：数据库调优、数据库问题定位、高性能数据库表设计等；
掌握技术面，已经是某个领域的专家了，简单来说就是这个领域的问题找你都可以搞定。
技术体
“体”就是多个技术面的综合。
最常见的“体”就是架构设计，对于一个大型业务或者系统的架构师来说，需要掌握多个技术面，然后进行设计和取舍。例如，一个后台架构师需要掌握 Java 的技术面、数据库的技术面、网络的技术面等，以及业务领域知识。
架构设计是横向技术面的综合，我称之为广度技术体；还有一种纵向技术面的综合，我称之为深度技术体。例如 Java 的开发工程师，当达到技术面的水平时掌握了“多线程、JDBC、文件读写、JVM 调优、JVM 工具等”，如果需要进一步在 Java 这个领域提升技术，就需要向下了解操作系统、硬件（CPU、内存、磁盘等），从而更好的解决某些复杂的问题，例如 Disruptor 高性能并发框架的设计。掌握了技术体，就可以进行架构设计，或者成为某个领域的资深专家了，解决领域级的复杂问题。
软实力
发现问题
有的问题很明显，例如线上出故障，系统性能不达标，系统性能需要达到 5W QPS；但有的问题并不那么明显，并不能一眼看出是问题在哪里，是技术问题还是管理问题。
例如我们曾遇到团队间协作开发效率很低，每次开发一个业务功能，都需要几个系统的研发人员来讨论接口协议、接口数据格式、接口安全加密、业务逻辑等，大家都不厌其烦，但好像又都必不可少，团队间为了提高效率，项目经理制定了规范、流程、模板等，但作用最终都不大。那后来是怎么解决的呢？通过引入服务中心来完成系统间同步接口调用，通过引入消息队列来完成系统间异步消息通知，系统间协作效率大大提高，以前要开会讨论几个小时的事情，现在只要明确接口传输的数据内容即可，甚至都不用开会，两个研发一讨论就差不多了。
除此以外，问题的根源往往掩盖在很多问题表象之下，如果不解决根源问题，解决一个表象问题，获得一时安宁，一段时间后又发生另外的问题，长此以往反反复复。
例如我们曾有个系统，今天交换机故障导致业务问题，明天系统 bug 导致业务问题，后天机柜断电导致业务问题，还被黑客攻击过，这些问题看起来都很独立，问题的发生也感觉都是偶然的，按照出一个问题解决一个问题的方式也没什么问题，但全年来看，业务就是出了很多问题，怎么解决？我们经过分析，发现根本原因是业务需要异地多活，而架构是双机房单中心的，我们需要做到的不是避免每个问题的发生（事实上也不可能避免），而是应该做到问题发生后能够快速处理，于是通过将架构重构为异地多活，重构完成后还是有各种偶发问题发生，但对业务的影响就很小了。
发现问题的能力主要来源于经验，包括成功的经验、踩坑的经验、参考别人的经验，因此如果要培养自己这方面的能力，多思考、多总结、多学习、多参加行业交流。
技术创新
达到这个级别基本都是业界大神一般的级别，说实话我也没什么经验，只能仰慕这些大神。
例如：
- 当年贝索斯要求亚马逊公司内的系统都服务化，后来是哪位大神想到可以把这个能力开放出来转换为“云计算”？
- 阿里云王坚博士当年在众人都不看好的情况下为何坚持云计算是未来？
- Google 在解决大数据问题时，如何能够提炼出三篇论文，开启了一个大数据时代？
技术实力案例点评
一个面试者面试 Java P7，其中有一项项目经验很牛逼：XX 架构重构，性能提升 10 倍。于是，我针对这个项目经验进行了深入的考察，结果……
下面是我们大概的对话过程：
我：请简单介绍一下这个项目重构。
面：我们某个业务和运动会有关，每次关键比赛前业务访问量是平时的 10 倍以上，原来的系统量一大就卡死了，用户体验很不好，需要重构。
我：具体怎么做的呢？
面：我通过引入 mc 缓存，将原来直接访问数据库的操作改为先访问缓存，性能比原来提升了 10 倍。
我：为何你想到了引入 mc？
面：（卡了一下，有点惊讶我的问题）……我上网查了一下资料，很多都说 mc 能够大幅提升性能，并且使用后确实效果很好。
[点评 1] 这是典型的“代码靠抄，方案靠搜，效果靠试”，面试者看到了一个问题，但没有分析和思考，然后上网搜方案，看到了好像很多人都说引入 mc 都能解决问题，关键是最终确实好像解决了，这让面试者自我感觉良好。
我：mc 能大幅提升性能的原理是什么？
面：缓存访问快，数据库访问慢。
我：那 mc 性能多高，数据库性能多高？
面：……（想了 10 秒）抱歉，没有研究过。
[点评 2] 这是典型的知其然不知其所以然，开源方案拿来就用，基本的测试和原理研究都没做过。
我：没关系，那我们换个问题，重构后你们的系统用到的机器数量是多少？相比重构前减少了多少？
面：机器数量是 100 台，相比重构前没有减少。
我：哦，100 台机器，QPS 每台才 300 多，我看你们的业务也不是很复杂，为何这么低？
面：……（卡住 10 秒）这……300 多 QPS 好像也不低吧？
我：那你有没有分析过每次请求全流程每个阶段的性能耗时？瓶颈在哪里？
面：（卡住 5 秒）没有分析过呢？
我：那为何就认定引入 mc 就有效果？
面：……（卡住 10 秒）我看大家都说引入缓存能大幅提升性能，而且最终效果确实很好。
[点评] 这就是知道技术点，不知道技术线和技术面，按道理对于系统性能问题的分析，至少是技术线级别的，需要分析每个请求每个阶段的耗时和原因；也可以是技术面级别的，例如分析数据库的设计、服务器的负载均衡等，还可以是技术体级别的，例如架构是否合理，是否可以将某个子系统拆分，引入消息队列等。
我：好吧，换个问题，如果让你再一次优化系统，你觉得可以怎么做？
面：……（思考 20 秒）我觉得目前的系统性能已经足够，应该不需要优化了。
[点评] 考察的是发现问题的能力，但他发现不了问题，其实前面已经都提到了，100 台机器就是问题，QPS 过低也是问题，但由于他没有经验，是看不出这些问题的。
很遗憾，最终这个面试者没有通过面试。
知识来源：从0开始学架构