登录 注册
开源 企业版 高校版 私有云 Gitee AI NEW
扫描微信二维码支付
取消
支付完成
Watch
不关注 关注所有动态 仅关注版本发行动态 关注但不提醒动态
1 Star 0 Fork 228

谭晓憨 / architect-all

forked from cfm / architect-all 
代码 Issues 0 Pull Requests 0 Wiki 统计 流水线
服务
加入 Gitee
与超过 1200万 开发者一起发现、参与优秀开源项目，私有仓库也完全免费 ：）
免费加入
克隆/下载
README.md 107.67 KB
一键复制 编辑 原始数据 按行查看 历史
cfm 提交于 2018-04-09 22:23 . 更新 README.md

architect-all

后端架构师技术图谱 此为markdown文档 安装

最后更新于2018-04-09 晚

数据结构

队列

集合

链表、数组

字典、关联数组

树

二叉树

每个节点最多有两个叶子节点。

完全二叉树

  • 《完全二叉树》
    • 叶节点只能出现在最下层和次下层，并且最下面一层的结点都集中在该层最左边的若干位置的二叉树。

平衡二叉树

左右两个子树的高度差的绝对值不超过1，并且左右两个子树都是一棵平衡二叉树。

红黑树

B-，B+，B*树

MySQL是基于B+树聚集索引组织表

常用算法

排序、查找算法

选择排序

冒泡排序

插入排序

快速排序

归并排序

堆排序

计数排序

桶排序

基数排序

按照个位、十位、百位、...依次来排。

二分查找

Java 中的排序工具

贪心算法

回溯算法

剪枝算法

动态规划

朴素贝叶斯

推荐算法

并发

多线程

线程安全

一致性、事务

事务 ACID 特性

事务的隔离级别

  • 未提交读：一个事务可以读取另一个未提交的数据，容易出现脏读的情况。

  • 读提交：一个事务等另外一个事务提交之后才可以读取数据，但会出现不可重复读的情况（多次读取的数据不一致），读取过程中出现UPDATE操作，会多。（大多数数据库默认级别是RC，比如SQL Server，Oracle），读取的时候不可以修改。

  • 可重复读： 读取的时候就锁定，不可修改（会影响更新），Mysql InnoDB 就是这个级别。

  • 序列化：所有事物串行处理（牺牲了效率）

  • 《理解事务的4种隔离级别》

  • 数据库事务的四大特性及事务隔离级别

锁

Java中的锁和同步类

公平锁 & 非公平锁

公平锁的作用就是严格按照线程启动的顺序来执行的，不允许其他线程插队执行的；而非公平锁是允许插队的。

悲观锁 & 乐观锁 & CAS

ABA 问题

由于高并发，在CAS下，更新后可能此A非彼A。通过版本号可以解决，类似于上文Mysql 中提到的的乐观锁。

CopyOnWrite容器

可以对CopyOnWrite容器进行并发的读，而不需要加锁。CopyOnWrite并发容器用于读多写少的并发场景。比如白名单，黑名单，商品类目的访问和更新场景，不适合需要数据强一致性的场景。

RingBuffer

可重入锁 & 不可重入锁

  • 《可重入锁和不可重入锁》

    • 通过简单代码举例说明可重入锁和不可重入锁。
    • 可重入锁指同一个线程可以再次获得之前已经获得的锁。
    • 可重入锁可以用户避免死锁。
    • Java中的可重入锁：synchronized 和 java.util.concurrent.locks.ReentrantLock

  • 《ReenTrantLock可重入锁（和synchronized的区别）总结》

    • synchronized 使用方便，编译器来加锁，是非公平锁。
    • ReenTrantLock 使用灵活，锁的公平性可以定制。
    • 相同加锁场景下，推荐使用 synchronized。

操作系统

计算机原理

进程

TODO

线程

TODO

协程

TODO

Linux

设计模式

23种常见设计模式

责任链模式

MVC

IOC

  • 《理解 IOC》
  • 《IOC 的理解与解释》
    • 正向控制：传统通过new的方式。反向控制，通过容器注入对象。
    • 作用：用于模块解耦。
    • DI：Dependency Injection，即依赖注入，只关心资源使用，不关心资源来源。

AOP

UML

微服务思想

康威定律

  • 《微服务架构的理论基础 - 康威定律》
    • 定律一：组织沟通方式会通过系统设计表达出来，就是说架构的布局和组织结构会有相似。
    • 定律二：时间再多一件事情也不可能做的完美，但总有时间做完一件事情。一口气吃不成胖子，先搞定能搞定的。
    • 定律三：线型系统和线型组织架构间有潜在的异质同态特性。种瓜得瓜，做独立自治的字系统减少沟通成本。
    • 定律四：大的系统组织总是比小系统更倾向于分解。合久必分，分而治之。

运维 & 统计 & 技术支持

常规监控

命令行监控工具

APM

APM — Application Performance Management

统计分析

持续集成

Jenkins

环境分离

开发、测试、生成环境分离。

自动化运维

Ansible

puppet

chef

测试

TDD 理论

  • 《深度解读 - TDD（测试驱动开发）》
    • 基于测试用例编码功能代码，XP（Extreme Programming）的核心实践.
    • 好处：一次关注一个点，降低思维负担；迎接需求变化或改善代码的设计；提前澄清需求；快速反馈；

单元测试

压力测试

全链路压测

A/B Test

虚拟化

KVM

Xen

OpenVZ

容器技术

Docker

云技术

OpenStack

DevOps

文档管理

中间件

Web Server

Nginx

OpenResty

Apache Httpd

Tomcat

Jetty

  • 《Jetty 的工作原理以及与 Tomcat 的比较》
  • 《jetty和tomcat优势比较》
    • 架构比较:Jetty的架构比Tomcat的更为简单。
    • 性能比较：Jetty和Tomcat性能方面差异不大，Jetty默认采用NIO结束在处理I/O请求上更占优势，Tomcat默认采用BIO处理I/O请求，Tomcat适合处理少数非常繁忙的链接，处理静态资源时性能较差。
    • 其他方面：Jetty的应用更加快速，修改简单，对新的Servlet规范的支持较好;Tomcat 对JEE和Servlet 支持更加全面。

缓存

本地缓存

客户端缓存

Memcached

Redis

  • 《Redis 教程》
  • 《redis底层原理》
    • 使用 ziplist 存储链表，ziplist是一种压缩链表，它的好处是更能节省内存空间，因为它所存储的内容都是在连续的内存区域当中的。
    • 使用 skiplist(跳跃表)来存储有序集合对象、查找上先从高Level查起、时间复杂度和红黑树相当，实现容易，无锁、并发性好。
  • 《Redis持久化方式》
    • RDB方式：定期备份快照，常用于灾难恢复。优点：通过fork出的进程进行备份，不影响主进程、RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。缺点：会丢数据。
    • AOF方式：保存操作日志方式。优点：恢复时数据丢失少，缺点：文件大，回复慢。
    • 也可以两者结合使用。

Tair

  • 官方网站
  • 《Tair和Redis的对比》
  • ​
  • 特点：可以配置备份节点数目，通过异步同步到备份节点
  • 一致性Hash算法。
  • 架构：和Hadoop 的设计思想类似，有Configserver，DataServer，Configserver 通过心跳来检测，Configserver也有主备关系。

几种存储引擎:

  • MDB，完全内存性，可以用来存储Session等数据。
  • Rdb（类似于Redis），轻量化，去除了aof之类的操作，支持Restfull操作
  • LDB（LevelDB存储引擎），持久化存储，LDB 作为rdb的持久化，google实现，比较高效，理论基础是LSM(Log-Structured-Merge Tree)算法，现在内存中修改数据，达到一定量时（和内存汇总的旧数据一同写入磁盘）再写入磁盘，存储更加高效，县比喻Hash算法。
  • Tair采用共享内存来存储数据，如果服务挂掉（非服务器），重启服务之后，数据亦然还在。

消息队列

消息总线

消息总线相当于在消息队列之上做了一层封装，统一入口，统一管控、简化接入成本。

RabbitMQ

支持事务，推拉模式都是支持、适合需要可靠性消息传输的场景。

RocketMQ

Java实现，推拉模式都是支持，吞吐量逊于Kafka。可以保证消息顺序。

ActiveMQ

纯Java实现，兼容JMS，可以内嵌于Java应用中。

Kafka

高吞吐量、采用拉模式。适合搞IO场景，比如日志同步。

Redis 消息推送

生产者、消费者模式完全是客户端行为，list 和 拉模式实现，阻塞等待采用 blpop 指令。

ZeroMQ

TODO

定时调度

单机定时调度

分布式定时调度

RPC

Dubbo

Thrift

gRPC

服务端可以认证加密，在外网环境下，可以保证数据安全。

数据库中间件

Sharding Jdbc

日志系统

日志搜集

配置中心

servlet 3.0 异步特性可用于配置中心的客户端

API 网关

主要职责：请求转发、安全认证、协议转换、容灾。

网络

协议

TCP/IP

HTTP

HTTP2.0

HTTPS

网络模型

  • 《web优化必须了解的原理之I/o的五种模型和web的三种工作模式》

    • 五种I/O模型：阻塞I/O，非阻塞I/O，I/O复用、事件(信号)驱动I/O、异步I/O，前四种I/O属于同步操作，I/O的第一阶段不同、第二阶段相同，最后的一种则属于异步操作。
    • 三种 Web Server 工作方式：Prefork(多进程)、Worker方式(线程方式)、Event方式。

  • 《select、poll、epoll之间的区别总结》

    • select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的。
    • select 有打开文件描述符数量限制，默认1024（2048 for x64），100万并发，就要用1000个进程、切换开销大；poll采用链表结构，没有数量限制。
    • select，poll “醒着”的时候要遍历整个fd集合，而epoll在“醒着”的时候只要判断一下就绪链表是否为空就行了，通过回调机制节省大量CPU时间；select，poll每次调用都要把fd集合从用户态往内核态拷贝一次，而epoll只要一次拷贝。
    • poll会随着并发增加，性能逐渐下降，epoll采用红黑树结构，性能稳定，不会随着连接数增加而降低。

  • 《select，poll，epoll比较 》

    • 在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。

  • 《深入理解Java NIO》

    • NIO 是一种同步非阻塞的 IO 模型。同步是指线程不断轮询 IO 事件是否就绪，非阻塞是指线程在等待 IO 的时候，可以同时做其他任务

  • 《BIO与NIO、AIO的区别》

  • 《两种高效的服务器设计模型：Reactor和Proactor模型》

Epoll

NIO

kqueue

框架

序列化(二进制协议)

Hessian

Protobuf

#数据库

MySQL

原理

优化

NoSQL

MongoDB

  • MongoDB 教程
  • 《Mongodb相对于关系型数据库的优缺点》
    • 优点：弱一致性（最终一致），更能保证用户的访问速度；内置GridFS，支持大容量的存储；Schema-less 数据库，不用预先定义结构；内置Sharding；相比于其他NoSQL，第三方支持丰富；性能优越；
    • 缺点：mongodb不支持事务操作；mongodb占用空间过大；MongoDB没有如MySQL那样成熟的维护工具，这对于开发和IT运营都是个值得注意的地方；

Hbase

搜索引擎

搜索引擎原理

Lucene

Elasticsearch

Solr

sphinx

性能

性能优化方法论

容量评估

CDN 网络

连接池

性能调优

#大数据

流式计算

Storm

Flink

Kafka Stream

应用场景

例如：

  • 广告相关实时统计；
  • 推荐系统用户画像标签实时更新；
  • 线上服务健康状况实时监测；
  • 实时榜单；
  • 实时数据统计。

Hadoop

HDFS

MapReduce

Yarn

Spark

安全

web 安全

XSS

CSRF

SQL 注入

脚本注入

漏洞扫描工具

验证码

DDoS 防范

加密解密

对称加密

  • 《常见对称加密算法》
    • DES、3DES、Blowfish、AES
    • DES 采用 56位秘钥，Blowfish 采用1到448位变长秘钥，AES 128，192和256位长度的秘钥。
    • DES 秘钥太短（只有56位）算法目前已经被 AES 取代，并且 AES 有硬件加速，性能很好。

哈希算法

非对称加密

服务器安全

数据安全

数据备份

TODO

网络隔离

内外网分离

TODO

登录跳板机

在内外环境中通过跳板机登录到线上主机。

授权

RBAC

OAuth2.0

常用开源框架

开源协议

日志框架

Log4j、Log4j2

Logback

ORM

MyBatis：

网络框架

TODO

Web 框架

Spring 家族

** Spring Boot **

** Spring Cloud **

工具框架

分布式设计

扩展性设计

稳定性 & 高可用

  • 《系统设计：关于高可用系统的一些技术方案》

    • 可扩展：水平扩展、垂直扩展。 通过冗余部署，避免单点故障。
    • 隔离：避免单一业务占用全部资源。避免业务之间的相互影响 2. 机房隔离避免单点故障。
    • 解耦：降低维护成本，降低耦合风险。减少依赖，减少相互间的影响。
    • 限流：滑动窗口计数法、漏桶算法、令牌桶算法等算法。遇到突发流量时，保证系统稳定。
    • 降级：紧急情况下释放非核心功能的资源。牺牲非核心业务，保证核心业务的高可用。
    • 熔断：异常情况超出阈值进入熔断状态，快速失败。减少不稳定的外部依赖对核心服务的影响。
    • 自动化测试：通过完善的测试，减少发布引起的故障。
    • 灰度发布：灰度发布是速度与安全性作为妥协，能够有效减少发布故障。

  • 《关于高可用的系统》

    • 设计原则：数据不丢(持久化)；服务高可用(服务副本)；绝对的100%高可用很难，目标是做到尽可能多的9，如99.999%（全年累计只有5分钟）。

硬件负载均衡

软件负载均衡

限流

  • 《谈谈高并发系统的限流》
    • 计数器：通过滑动窗口计数器，控制单位时间内的请求次数，简单粗暴。
    • 漏桶算法：固定容量的漏桶，漏桶满了就丢弃请求，比较常用。
    • 令牌桶算法：固定容量的令牌桶，按照一定速率添加令牌，处理请求前需要拿到令牌，拿不到令牌则丢弃请求，或进入丢队列，可以通过控制添加令牌的速率，来控制整体速度。Guava 中的 RateLimiter 是令牌桶的实现。
    • Nginx 限流：通过 limit_req 等模块限制并发连接数。

应用层容灾

  • 《防雪崩利器：熔断器 Hystrix 的原理与使用》

    • 雪崩效应原因：硬件故障、硬件故障、程序Bug、重试加大流量、用户大量请求。
    • 雪崩的对策：限流、改进缓存模式(缓存预加载、同步调用改异步)、自动扩容、降级。
    • Hystrix设计原则：
      • 资源隔离：Hystrix通过将每个依赖服务分配独立的线程池进行资源隔离, 从而避免服务雪崩。
      • 熔断开关：服务的健康状况 = 请求失败数 / 请求总数，通过阈值设定和滑动窗口控制开关。
      • 命令模式：通过继承 HystrixCommand 来包装服务调用逻辑。

  • 《缓存穿透，缓存击穿，缓存雪崩解决方案分析》

  • 《缓存击穿、失效以及热点key问题》

    • 主要策略：失效瞬间：单机使用锁；使用分布式锁；不过期；
    • 热点数据：热点数据单独存储；使用本地缓存；分成多个子key；

###跨机房容灾

  • 《“异地多活”多机房部署经验谈》

    • 通过自研中间件进行数据同步。

  • 《异地多活（异地双活）实践经验》

    • 注意延迟问题，多次跨机房调用会将延时放大数倍。
    • 建房间专线很大概率会出现问题，做好运维和程序层面的容错。
    • 不能依赖于程序端数据双写，要有自动同步方案。
    • 数据永不在高延迟和较差网络质量下，考虑同步质量问题。
    • 核心业务和次要业务分而治之，甚至只考虑核心业务。
    • 异地多活监控部署、测试也要跟上。
    • 业务允许的情况下考虑用户分区，尤其是游戏、邮箱业务。
    • 控制跨机房消息体大小，越小越好。
    • 考虑使用docker容器虚拟化技术，提高动态调度能力。

  • 容灾技术及建设经验介绍

    • ​

容灾演练流程

平滑启动

数据库扩展

读写分离模式

分片模式

  • 《分库分表需要考虑的问题及方案》

    • 中间件： 轻量级：sharding-jdbc、TSharding；重量级：Atlas、MyCAT、Vitess等。
    • 问题：事务、Join、迁移、扩容、ID、分页等。
    • 事务补偿：对数据进行对帐检查;基于日志进行比对;定期同标准数据来源进行同步等。
    • 分库策略：数值范围；取模；日期等。
    • 分库数量：通常 MySQL 单库 5千万条、Oracle 单库一亿条需要分库。

  • 《MySql分表和表分区详解》

    • 分区：是MySQL内部机制，对客户端透明，数据存储在不同文件中，表面上看是同一个表。
    • 分表：物理上创建不同的表、客户端需要管理分表路由。

服务治理

服务注册与发现

服务路由控制

  • 《分布式服务框架学习笔记4 服务路由》
    • 原则：透明化路由
    • 负载均衡策略：随机、轮询、服务调用延迟、一致性哈希、粘滞连接
    • 本地路由有限策略：injvm(优先调用jvm内部的服务)，innative(优先使用相同物理机的服务),原则上找距离最近的服务。
    • 配置方式：统一注册表；本地配置；动态下发。

分布式一致

CAP 与 BASE 理论

  • 《从分布式一致性谈到CAP理论、BASE理论》
    • 一致性分类：强一致(立即一致)；弱一致(可在单位时间内实现一致，比如秒级)；最终一致(弱一致的一种，一定时间内最终一致)
    • CAP：一致性、可用性、分区容错性(网络故障引起)
    • BASE：Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）
    • BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

分布式锁

  • 《分布式锁的几种实现方式》
    • 基于数据库的分布式锁：优点：操作简单、容易理解。缺点：存在单点问题、数据库性能够开销较大、不可重入；
    • 基于缓存的分布式锁：优点：非阻塞、性能好。缺点：操作不好容易造成锁无法释放的情况。
    • Zookeeper 分布式锁：通过有序临时节点实现锁机制，自己对应的节点需要最小，则被认为是获得了锁。优点：集群可以透明解决单点问题，避免锁不被释放问题，同时锁可以重入。缺点：性能不如缓存方式，吞吐量会随着zk集群规模变大而下降。
  • 《基于Zookeeper的分布式锁》
    • 清楚的原理描述 + Java 代码示例。

分布式一致性算法

####PAXOS

Zab

Raft

Gossip

两阶段提交、多阶段提交

幂等

  • 《分布式系统---幂等性设计》
    • 幂等特性的作用：该资源具备幂等性，请求方无需担心重复调用会产生错误。
    • 常见保证幂等的手段：MVCC（类似于乐观锁）、去重表(唯一索引)、悲观锁、一次性token、序列号方式。

分布式一致方案

分布式 Leader 节点选举

TCC(Try/Confirm/Cancel) 柔性事务

  • 《传统事务与柔性事务》
    • 基于BASE理论：基本可用、柔性状态、最终一致。
    • 解决方案：记录日志+补偿（正向补充或者回滚）、消息重试(要求程序要幂等)；“无锁设计”、采用乐观锁机制。

分布式文件系统

唯一ID 生成

全局唯一ID

  • 《高并发分布式系统中生成全局唯一Id汇总》

    • Twitter 方案（Snowflake 算法）：41位时间戳+10位机器标识（比如IP，服务器名称等）+12位序列号(本地计数器)
    • Flicker 方案：MySQL自增ID + "REPLACE INTO XXX:SELECT LAST_INSERT_ID();"
    • UUID：缺点，无序，字符串过长，占用空间，影响检索性能。
    • MongoDB 方案：利用 ObjectId。缺点：不能自增。

  • 《TDDL 在分布式下的SEQUENCE原理》

    • 在数据库中创建 sequence 表，用于记录，当前已被占用的id最大值。
    • 每台客户端主机取一个id区间（比如 1000~2000）缓存在本地，并更新 sequence 表中的id最大值记录。
    • 客户端主机之间取不同的id区间，用完再取，使用乐观锁机制控制并发。

一致性Hash算法

设计思想 & 开发模式

DDD(Domain-driven Design - 领域驱动设计)

  • 《浅谈我对DDD领域驱动设计的理解》

    • 概念：DDD 主要对传统软件开发流程(分析-设计-编码)中各阶段的割裂问题而提出，避免由于一开始分析不明或在软件开发过程中的信息流转不一致而造成软件无法交付（和需求方设想不一致）的问题。DDD 强调一切以领域（Domain）为中心，强调领域专家（Domain Expert）的作用，强调先定义好领域模型之后在进行开发，并且领域模型可以指导开发（所谓的驱动）。
    • 过程：理解领域、拆分领域、细化领域，模型的准确性取决于模型的理解深度。
    • 设计：DDD 中提出了建模工具，比如聚合、实体、值对象、工厂、仓储、领域服务、领域事件来帮助领域建模。

  • 《领域驱动设计的基础知识总结》

    • 领域（Doamin）本质上就是问题域，比如一个电商系统，一个论坛系统等。
    • 界限上下文（Bounded Context）：阐述子域之间的关系，可以简单理解成一个子系统或组件模块。
    • 领域模型（Domain Model）：DDD的核心是建立（用通用描述语言、工具—领域通用语言）正确的领域模型；反应业务需求的本质，包括实体和过程；其贯穿软件分析、设计、开发 的整个过程；常用表达领域模型的方式：图、代码或文字；
    • 领域通用语言：领域专家、开发设计人员都能立即的语言或工具。
    • 经典分层架构：用户界面/展示层、应用层、领域层、基础设施层，是四层架构模式。
    • 使用的模式：
      • 关联尽量少，尽量单项，尽量降低整体复杂度。
      • 实体（Entity）：领域中的唯一标示，一个实体的属性尽量少，少则清晰。
      • 值对象（Value Object）：没有唯一标识，且属性值不可变，小二简单的对象，比如Date。
      • 领域服务（Domain Service）： 协调多个领域对象，只有方法没有状态(不存数据)；可以分为应用层服务，领域层服务、基础层服务。
      • 聚合及聚合根（Aggregate，Aggregate Root）：聚合定义了一组具有内聚关系的相关对象的集合；聚合根是对聚合引用的唯一元素；当修改一个聚合时，必须在事务级别；大部分领域模型中，有70%的聚合通常只有一个实体，30%只有2~3个实体；如果一个聚合只有一个实体，那么这个实体就是聚合根；如果有多个实体，那么我们可以思考聚合内哪个对象有独立存在的意义并且可以和外部直接进行交互；
      • 工厂（Factory）：类似于设计模式中的工厂模式。
      • 仓储（Repository）：持久化到DB，管理对象，且只对聚合设计仓储。

  • 《领域驱动设计(DDD)实现之路》

    • 聚合：比如一辆汽车（Car）包含了引擎（Engine）、车轮（Wheel）和油箱（Tank）等组件，缺一不可。

  • 《领域驱动设计系列（2）浅析VO、DTO、DO、PO的概念、区别和用处》

命令查询职责分离(CQRS)

CQRS — Command Query Responsibility Seperation

贫血，充血模型

  • 《贫血，充血模型的解释以及一些经验》
    • 失血模型：老子和儿子分别定义，相互不知道，二者实体定义中完全没有业务逻辑，通过外部Service进行关联。
    • 贫血模型：老子知道儿子，儿子也知道老子；部分业务逻辑放到实体中；优点：各层单项依赖，结构清楚，易于维护；缺点：不符合OO思想，相比于充血模式，Service层较为厚重；
    • 充血模型：和贫血模型类似，区别在于如何划分业务逻辑。优点：Service层比较薄，只充当Facade的角色，不和DAO打交道、复合OO思想；缺点：非单项依赖，DO和DAO之间双向依赖、和Service层的逻辑划分容易造成混乱。
    • 肿胀模式：是一种极端情况，取消Service层、全部业务逻辑放在DO中；优点：符合OO思想、简化了分层；缺点：暴露信息过多、很多非DO逻辑也会强行并入DO。这种模式应该避免。
    • 作者主张使用贫血模式。

Actor 模式

TODO

响应式编程

TODO

项目管理

架构评审

重构

TODO

代码规范

RUP

看板管理

SCRUM

极限编程

TODO

敏捷开发

TODO

结对编程

TODO

通用业务术语

TODO

#技术趋势

TODO

#架构师素质

  • 《架构师画像》

    • 业务理解和抽象能力
    • NB的代码能力
    • 全面：1. 在面对业务问题上，架构师脑海里是否会浮现出多种技术方案；2. 在做系统设计时是否考虑到了足够多的方方面面；3. 在做系统设计时是否考虑到了足够多的方方面面；
    • 全局：是否考虑到了对上下游的系统的影响。
    • 权衡：权衡投入产出比；优先级和节奏控制；

  • 《关于架构优化和设计，架构师必须知道的事情》

    • 要去考虑的细节：模块化、轻耦合、无共享架构；减少各个组件之前的依懒、注意服务之间依懒所有造成的链式失败及影响等。
    • 基础设施、配置、测试、开发、运维综合考虑。
    • 考虑人、团队、和组织的影响。

  • 《如何才能真正的提高自己，成为一名出色的架构师？》

  • 《架构师的必备素质和成长途径》

    • 素质：业务理解、技术广度、技术深度、丰富经验、沟通能力、动手能力、美学素养。
    • 成长路径：2年积累知识、4年积累技能和祖内影响力、7年积累部门内影响力、7年以上积累跨部门影响力。

  • 《架构设计师—你在哪层楼？》

    • 第一层的架构师看到的只是产品本身
    • 第二层的架构师不仅看到自己的产品，还看到了整体的方案
    • 第三层的架构师看到的是商业价值

团队管理

TODO

资讯

行业资讯

公众号列表

TODO

博客

团队博客

个人博客

综合门户、社区

国内：

国外：

问答、讨论类社区

行业数据分析

专项网站

其他类

推荐参考书

在线电子书

纸质书

架构方面

技术管理方面

工具方面

TODO

大数据方面

技术资源

开源资源

手册

  • W3Cschool
  • Runoob.com
    • HTML 、 CSS、XML、Java、Python、PHP、设计模式等入门手册。

在线课堂

会议

工具

代码托管

文件服务

  • 七牛
  • 又拍云

综合云服务商

  • 阿里云
  • 腾讯云
  • 百度云
  • 新浪云
  • 金山云
其他
1
https://gitee.com/tan-xiaohan/architect-all.git
git@gitee.com:tan-xiaohan/architect-all.git
tan-xiaohan
architect-all
architect-all
master
点此查找更多帮助

搜索帮助

Git 命令在线学习 如何在 Gitee 导入 GitHub 仓库
Git 仓库基础操作
企业版和社区版功能对比
SSH 公钥设置
如何处理代码冲突
仓库体积过大，如何减小？
如何找回被删除的仓库数据
Gitee 产品配额说明
GitHub仓库快速导入Gitee及同步更新
什么是 Release（发行版）
将 PHP 项目自动发布到 packagist.org
评论
仓库举报
回到顶部