程序员进阶架构师路线

2022年05月15日阅读数：5

这篇文章主要向大家介绍程序员进阶架构师路线,主要内容包括基础应用、实用技巧、原理机制等方面，希望对大家有所帮助。

标签：前端 java 程序员 redis spring sql 数据库编程后端设计模式

做者简介：曾任职于阿里巴巴，每日优鲜等互联网公司，任技术总监，15年电商互联网经历。前端

下面是做者根据本身15年的互联网电商经验总结的，Java程序员进阶架构师的路线图，但愿对初入职场的同窗和对本身技术发展路线不太明确的同窗有所帮助！
java

Java程序员进阶架构师学习路线图（双击查看清晰大图）：
程序员

详细介绍以下：
redis

JVMspring

基本参数调优（Xmx，Xms，Xss，-XX:NewRatio，-XX:SurvivorRatio等）sql
GC收集器选择（根据系统特色，好比是吞吐量优先仍是响应时间优先，老年代和新生代选择什么收集器，选择Serial，Parallel，CMS仍是G1等）数据库
常见JVM问题（OOM，内存泄漏，频繁Full GC，线程阻塞等）编程
关键命令应用（Jmap，Jstack，Jstat，jps，jinfo等）后端
内存模型设计模式

Java基础

集合类
锁（自旋锁，可重入锁，偏向锁，乐观锁，悲观锁等等概念的理解）
并发编程

- 并发包（java.util.concurrent）
- 原子包 java.util.concurrent.atomic

4. 设计模式

数据迁移

数据结构不变（加从库）
数据结构改变（双写双读）

详见做者原创文章《服务化带来的问题---之数据迁移经历》

数据一致性

强一致（XA，两阶段提交）
最终一致，补偿机制（Tcc，Saga，Seata，事务型消息等，详见做者原创文章《服务化带来的数据一致问题---分布式事务，事务型消息》）
幂等性（一个操做访问屡次，结果都同样。好比支付接口要保证幂等，因为网络等缘由接口重试后，不能屡次扣款）

服务网关（Zuul，Gateway等）

流控，限流（总体限流，避免突发流量给系统带来过大压力；对用户限流，防脚本、机器人刷单）
熔断（下游服务出问题，上游服务再也不继续发送请求到下游服务，直接快速返回默认数据，避免线程长时间阻塞形成线程池线程耗尽；下游服务压力获得缓解，恢复概率也会变大）
鉴权（好比token验证，能够在网关层处理）
路由（根据请求路径等信息，将请求路由到相应的服务上）
黑白名单
接口聚合（将同一个页面多个接口的返回结果聚合成一个返回给前端，减小网络访问频次）

服务治理

服务发现（在服务节点上下线过程当中，自动发现服务节点，无需人工介入）
负载均衡
限流（网关层总体限流，避免突发流量给系统带来过大压力；对用户限流，防脚本、机器人刷单）
熔断（开源熔断组件hystrix、resilience4j等。下游服务出问题，上游服务再也不继续发送请求到下游服务，直接快速返回默认数据，避免线程长时间阻塞形成线程池线程耗尽；下游服务压力获得缓解，恢复概率也会变大）
资源隔离（分组部署，jvm内部线程隔离）
配置中心（配置和代码分离，灵活支持生产，测试和开发环境；提升安全性，提升修改配置效率）
服务降级（除了，限流、熔断等；还能够对部分性能差的接口和功能设置开关，好比咱们会在大促期间关闭物流查询接口，来保证系统性能；降级方案内容太多了，这里不作过多描述）

应用缓存

缓存分类

- 本地缓存（应用内部的缓存，好比guava cache等，特色：本地内存直接读取，速度快；存储量小，适合少许且相对稳定的数据；分布式多节点部署，可能会出现多个节点本地缓存数据不一致的状况）
- 缓存中间件（如Redis等，单独部署的中间件，存储量大；遇到瓶颈时能够作集群分片）

2. 常见问题

- 缓存穿透（对于数据库中根本不存在的值，请求缓存时要在缓存记录一个空值，避免每次请求都打到数据库）
- 缓存热点（有些热点数据访问量会特别大，单个缓存中间件节点（例如Redis）没法支撑这么大的访问量。若是是读请求访问量大，能够考虑读写分离，一主多从的方案，用从节点分摊读流量；若是是写请求访问量大，能够采用集群分片方案，用分片分摊写流量）
- 缓存雪崩（在某一时间段缓存数据集中失效，致使大量请求穿透到数据库。能够在初始化数据时，差别化各个key的缓存失效时间，失效时间 = 一个较大的固定值 + 较小的随机值）

异步消息

应用场景（异步处理，流量消峰，一对多通讯，日志处理，系统解耦等）
带来的问题（过多的异步消息使用和滥用，会让代码阅读者感受混乱，使系统的调用关系变复杂，系统可维护性会变差）

数据库

关系型数据库

- 数据库性能优化（数据库服务端参数调优，好比调整查询缓存大小等）
- 应用优化
- A. 引擎选择（例如Mysql的InnoDB，MyIsam，Memory等）
  
  B. 索引优化（数据存储和索引原理，联合索引，覆盖索引，索引下推等都要了解）
- 高并发场景海量数据解决方案

1. 1. 分库分表（对于数据量特别大，并且访问量大的数据库表，能够分表分库来解决数据库写入和读取瓶颈）
  2. 批量异步写入（采用异步批量写表的方式，减小表写入频次，进而减小表的写入压力）
  3. 冷热分离（冷热数据分开存储，减小单表数据量，从而提升写入和查询性能）
  4. 读写分离（写主库，读从库，用从库分摊读流量，从库能够是一个或多个，减小了主库压力）

2.非关系数据库（NOSQL。像MongoDB等。不过重要的数据、评论评价、业务操做日志等能够用非关系数据库存储。使用过程要注意坑，篇幅缘由不作详细介绍)

高并发场景解决方案

CDN （页面静态化，用CDN扛流量（扛访问量，扛带宽））
应用缓存（缓存中间件（Redis等），本地缓存（Guava cache等））
异步通讯（消息队列，解耦、消峰、减小线程阻塞）
分库分表（对于数据量特别大，并且访问量大的数据库表，能够分表分库来解决数据库写入和读取瓶颈）
JVM优化（基本参数优化，选择合适的垃圾回收器）
带宽考虑（避免带宽称为瓶颈，促销和秒杀开始前提早申请带宽。不光要考虑外网带宽，还要考虑内网带宽，有些旧服务器网口是千兆网口，访问量高时极可能会打满）

秒杀场景设计

关键点：页面静态化，页面拦截请求，网关拦截请求，批量异步写数据库。详情参考做者原创

《秒杀系统设计～亿级用户》

关于快速迭代

高可维护性

API封装（对组件API进行封装，若是更换组件，好比jedis换成spring-data-redis，能够直接修改API层，避免全部引用API的地方都须要变化）
高可读性（可读性高的设计和代码，可维护性也会很好）
高可复用性（可复用性高的设计和代码，可维护性也会很好）
合理的服务拆分（服务拆分合理，不一样的服务由不一样的组或我的维护，可维护性会大大提升）

2. 水平扩展能力

性能瓶颈（避免数据库，缓存中间件，消息队列，网络等称为系统瓶颈，保证系统水平扩展能力）
服务注册发现（在服务节点上下线过程当中，自动发现服务节点，无需人工介入）

3. 中台思想

- 共享服务（中台思想的前奏，以电商为例，将订单、商品、交易等等稳定业务抽出作成共享服务，避免一个企业内部不一样团队的重复开发和重复维护工做，可以快速应对业务变化）
- 中台思想（大中台，小前台。以电商为例，将订单、商品、交易等等稳定业务逐渐沉淀到中台，有新增业务或者业务发生变化时，前台业务能够基于中台服务快速完成系统迭代）

关于高可用（避免单点问题，保证持续提供服务）

发布部署

灰度发布设计（为避免线上全盘错误或系统崩溃，C端功能须要灰度上线，再逐步增大流量）
流量摘除（在节点重启以前要提早摘除该节点上的访问流量，避免重启过程访问错误，进而影响用户体验）
隔离部署/分组部署（为了不相互影响，后端运营系统和C端服务所依赖的共同服务须要隔离部署。秒杀和平常交易所依赖的订单服务和库存等服务也要隔离部署）
CI（持续集成）
CD（持续部署）

监控

运维监控（CPU，内存，网络等监控）
全链路监控（APM）（Pinpoint、Skywalking等全链路监控工具，能够监控跨系统跨服务的整个调用链路。对发现问题、排查问题和及时预警有很大帮助，还支持服务调用关系网络拓扑图）
业务监控（对业务异常进行监控，好比优惠券使用异常、刷单问题等）

容器技术

Docker（开源应用容器引擎）
Kubernetes（Google开源的一个容器编排引擎，让部署容器化的应用简单而且高效）

DEVOPS

（用工具系统的方式，将研发，测试和运维过程串联起来，减小彼此间沟通成本，下降因为沟通问题出错的概率）

性能测试（对to C的互联网系统，稳定性很是重要，性能测试是必须的，除了作测试环境压测外，还能够按期作线上全链路压测）
自动化测试（快速迭代过程，不少代码可能会影响到全局，须要作回归测试，测试人员很难覆盖到全部用例。不少公司在自动化测试投入大量人力，保证上线质量的同时，还能节省人力）
CI测试（持续集成测试，每次有代码变更构建（编译）工程时自动执行一遍测试用例，保证代码的新增和改动不影响原有功能，适用于测试用例不须要常常变化的成熟稳定业务）
功能测试

CDN