知识体系导读

大约 37 分钟

你好，我是 fly。我也曾疲于奔命各种新的技术或者知识，也曾每天在碎片化的学习中焦虑， 是否你也和我一样，羡慕他人拥有非同一般的技术影响力， 那么跟随我，结合一线大厂面试题帮你构筑你自己的知识体系， 当你掌握文中的知识体系之时，你会发现你已经成为了别人眼中的大佬。 但你依然要保持谦卑，敬畏技术，热爱生命。@fly#

知识体系技能地图概览

基础技能地图
基础技能地图

为了大家看得清楚，我切了两个大图

掌握部分
掌握部分
了解部分
了解部分

适合什么样的人群阅读

  • 面试官：系统性的理解不仅能帮助你理解知识的基础体系，更能帮快速甄别候选人才
  • 开发入门者：提前上船，赢在起跑线
  • 开发进阶者：若干年的开发，尚还没有方向的
  • 是个想上进的：关键是你觉得对你有意义，且做你认为正确的事就够了

Java入门与进阶

面向对象与Java基础

知识体系系统性梳理

架构视图
架构视图

Java进阶 - 集合框架

知识体系系统性梳理

Java进阶 - 并发框架

知识体系系统性梳理

img
img

数据结构与算法

数据结构基础

知识体系系统性梳理

数据库理论与实践

知识体系系统性梳理

开发与常用基础

知识体系系统性梳理

开发之常用类库

框架与中间件

Web容器 - Tomcat详解

Spring技术栈

SpringFramework框架详解

SpringBoot入门(helloworld,banner,logback,分层设计)

开发与工具

#open in new window开发百宝箱（常用资源）

#open in new window开发工具清单

开发工具详解

  • 常用软件工具
  • 工具详解 - Git
    • Git是分布式代码托管的标杆，这里将提供如何学习Git，以及Git工作流的总结，和常用的操作命令
  • 工具详解 - Eclipse,STS,IDEA
    • 本文总结常用的IDE工具
  • 工具详解 - Maven项目构建
  • 工具详解 - Jenkins+Gitlab
    • 使用Jenkins+Gitlab搭建CI环境

Linux相关

Linux 基础和常用工具总结。

  • Linux - Linux基础知识
    • Linux基础知识学习梳理
  • Linux - Linux 常用
    • 本文记录常用的Linux命令, 主要使用CentOS7
  • Linux - Curl使用
    • 主要总结Linux Curl的一些常见用法
  • Linux - Linux创建自建服务
    • 以打包自己开发的Java应用到Linux服务器，作为一个服务启动，并开启自启。
  • Linux - 内存分析工具pmap
    • pmap工具是linux的工具,能够查看进程用了多少内存,还能分析内存用在上面环节,对于一些长期占用内存居高不下的程序可以分析其行为,命令简单,信息简洁。
  • Linux - 零拷贝技术
    • 磁盘可以说是计算机系统最慢的硬件之一，读写速度相差内存 10 倍以上，所以针对优化磁盘的技术非常的多，比如零拷贝、直接 I/O、异步 I/O 等等，这些优化的目的就是为了提高系统的吞吐量，另外操作系统内核中的磁盘高速缓存区，可以有效的减少磁盘的访问次数。
  • Linux - ab压力测试
    • ab是apachebench命令的缩写, apache自带的压力测试工具。ab非常实用，它不仅可以对apache服务器进行网站访问压力测试，也可以对或其它类型的服务器进行压力测试。

Docker相关

  • Docker - Overview
  • 虚拟化技术 - Docker Vs. 虚拟机
    • 人们为了提高系统及硬件资源的利用率而引入了虚拟化技术。虚拟化是一种资源管理技术，它可以各种实体资源抽像后再分隔，从而打破实体结构的限制，最大程度的提高资源的利用率。Docker属于软件虚拟化技术中的操作系统层虚拟化技术，它是基于LXC实现的一个应用容器引擎，Docker让开发者可以打包他们的应用及依赖环境到一个可移植的容器中，然后可以将这个容器快速部署开发、测试或生产环境中。了解本文从三个问题着手，什么是虚拟化技术，docker和虚拟机区别，docker可以用来做什么？
  • Docker基础 - 入门基础和Helloworld
    • 在了解了虚拟化技术和Docker之后，让我们上手Docker，看看Docker是怎么工作的。这里会介绍CentOS环境下Docker的安装和配置，以及会给你展示两个实例，给你一个直观的理解。再啰嗦下，有条件的情况下直接看官网在新窗口打开open in new window, 网上资料鱼龙混杂，版本也更新不及时。
  • Docker基础 - 仓库，镜像，容器详解
    • 本文将从仓库，镜像，容器三个方面讲解常用的docker命令和使用等，对于开发而言这块使用的
  • Docker基础 - 一个web应用运行实例
    • 通过上文我们已经基本了解了docker的结构（仓库，镜像，容器）以及跑docker应用了；本文将通过介绍一个web应用：向你展示如何进行主机与web容器之间的通信，这是web开发者常用的；第二，贯穿上文中内容, 且为我们后续讲解网络提供基础
  • Docker基础 - Docker网络使用和配置
    • 上文已经向你介绍了，web容器创建和容器互联了，但是容器之间为什么可以直接通信？主机和容器之间为何可以通信？如何进行自定义的配置呢？所以这节就是我们要讲述的Docker网络。
  • Docker基础 - Docker数据卷和数据管理
    • Docker 容器的数据放哪里呢？ 本文带你理解如何在 Docker 内部以及容器之间管理数据。

开发与方法论

开发原则,流程,协议

相关文章

  • 软件开发中的原则 - SOLID
    • 在软件开发中，前人对软件系统的设计和开发总结了一些原则和模式， 不管用什么语言做开发，都将对我们系统设计和开发提供指导意义。本文主要将总结这些常见的原则，和具体阐述意义。
  • 分布式理论 - CAP
    • CAP理论是分布式系统、特别是分布式存储领域中被讨论的最多的理论。其中C代表一致性 (Consistency)，A代表可用性 (Availability)，P代表分区容错性 (Partition tolerance)。CAP理论告诉我们C、A、P三者不能同时满足，最多只能满足其中两个。
  • 分布式理论 - BASE
    • BASE是“Basically Available, Soft state, Eventually consistent(基本可用、软状态、最终一致性)”的首字母缩写。其中的软状态和最终一致性这两种技巧擅于对付存在分区的场合，并因此提高了可用性。
  • 事务理论 - ACID
    • 事务的四个基本特性
  • 康威定律 - 微服务基础
    • 微服务这个概念很早就提出了， 真正火起来是在2016年左右，而康威定律(Conway's Law)就是微服务理论基础。本文整理自肥侠的文章, 帮助大家理解微服务理论体系
  • 开发流程详解
    • 谈谈我常见的敏捷开发流程的理解
  • 开源协议详解
    • 开源不等于免费！为了加速我们的开发，我们会使用开源的软件和源码； 为避免商业风险，需要在使用时了解第三方如软件协议，版本，和已知CVE风险等；本文旨在从开源软件再发布过程使用权限的角度入手，总结各个常见开源协议的异同，方便理解。
  • 知识共享协议CC 4.0
    • 本文主要介绍知识共享许可协议，及本站遵守的多数站点会采用的知识共享协议CC BY-NC-SA 4.0协议，即署名-非商业性使用-相同方式共享协议。

代码规范

相关文章

  • 阿里巴巴 Java 开发手册
    • 《阿里巴巴 Java 开发手册》是阿里巴巴集团技术团队的集体经验总结，经历了多次大规模一线实战的检验及不断的完善，反馈给广大开发者。现代软件行业的高速发展对开发者的综合素质要求越来越高，因为不仅是编程知识点，其它维度的知识点也会影响到软件的最终交付质量。比如: 数据库的表结构和索引设计缺陷可能带来软件上的架构缺陷或性能风险；工程结构混乱导致后续维护艰难；没有鉴权的漏洞代码易被黑客攻击等等。所以本手册以 Java 开发者为中心视角，划分为编程规约、异常日志、MySQL 数据库、工程结构、安全规约五大块，再根据内容特征，细分成若干二级子目录。根据约束力强弱及故障敏感性，规约依次分为强制、推荐、参考三大类。对于规约条目的延伸信息中，“说明”对内容做了引申和解释；“正例”提倡什么样的编码和实现方式；“反例”说明需要提防的雷区，以及真实的错误案例。
  • Google Java 编程风格指南
  • Twitter Java Style Guide
    • 本文是Twitter的Java代码规范。

软件开发模式

软件开发模式相关文章。

相关文章

  • 传统模式 - 软件开发生命周期与过程模型(瀑布模型，原型模型和螺旋模型等）
    • 软件生命周期(Software Life Cycle,SLC)是软件的产生直到报废或停止使用的生命周期。软件生命周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级等阶段。那么如何将上述软件开发过程方法化呢？这就是过程模型。过程模型（Process Models） 意图解决软件过程中的混乱，将软件开发过程中的沟通、计划、建模、构建和部署等活动（activities）有效地组织了起来。他们之间的线性（linear）、迭代（iterative）、演进（evolutionary）和平行（parallel）关系会产生不同的模型。常见的过程模型包括：瀑布模型、原型模型、增量模型、螺旋模型等。
  • 传统模式 - 结合软件测试的过程模型演化:V模型,W模型,X模型等
    • 对于前文软件开发生命周期的实现，为保障软件质量，将测试工作凸显出来（通过前文介绍的线性（linear）、迭代（iterative）、演进（evolutionary）和平行（parallel）等方式），结合测试又演化出了针对测试的过程模型，主要有V模型,W模型,X模型,H模型等。
  • 敏捷开发 - 敏捷软件开发理论及流程
    • 敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
  • 敏捷开发 - 面向工程管理：极限编程（XP)
    • 极限编程（ExtremeProgramming，简称XP）是由KentBeck在1996年提出的，是一种软件工程方法学，是敏捷软件开发中可能是最富有成效的几种方法学之一。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。极限编程透过引入基本价值、原则、实践方法等概念来达到降低变更成本的目的。
  • 敏捷开发 - 面向过程管理：Scrum方式
    • Scrum是迭代式增量软件开发过程，是敏捷方法论中的重要框架之一，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum Master角色负责维护过程和任务，Product Owner代表利益所有者，Developer Team包括了所有开发人员。
  • 敏捷开发 - 面向过程管理：Kanban方式
    • 看板本身源于日本丰田公司对精益制造的实践，后延伸到敏捷开发领域；它的核心是JIT（Just In Time）: “让正确的物资，在正确的时间，流动到正确的地方，数量是刚刚好的数量。” 本文主要介绍看板的定义，核心实践以及在研发领域的实践等。
  • 敏捷开发 - 开发实践：测试驱动开发(TDD）
    • 测试驱动开发(Test Driven Development, 简称TDD)是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD的基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。本主要介绍TDD的基础和实践案例，以及很多团队无法使用TDD方式开发的一些思考。
  • 敏捷开发 - 开发实践：领域驱动开发(DDD）
    • TODO
  • 典型的中小团队开发流程详解
    • 通过典型的中小团队开发流程谈谈我对常见的敏捷开发流程的理解。
  • 精益企业 - 从组织的角度: 集成精益，敏捷，DevOPS等
    • Lean Enterprise （精益企业）是指一个产品系列价值流的不同部门同心协力消除浪费，并且按照顾客要求，来拉动生产。本文主要基于Scaled Agile, Inc. (SAI)公司的SAFe的框架（SAFe for Lean Enterprises）向你介绍精益企业的7个核心，并站在更高的视野层级上看敏捷和devops的位置，可以给你更多的启发。

企业开发认证

常见企业开发和系统认证相关文章。

相关文章

  • 能力成熟度模型集成认证 - CMMI
    • 在美国国防部的支持下，1987年，卡内基·梅隆大学软件工程研究所率先推出了软件工程评估项目的研究成果--软件过程能力成熟度模型（Capability Maturity Model of Software，即CMM），其研究目的是提供一种评价软件承接方能力的方法，同时它可帮助软件组织改进其软件过程。CMM是对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过这些阶段逐步提高。该能力成熟度模型使软件组织能够较容易的确定其当前过程的成熟度并识别其软件过程执行中的薄弱环节，确定对软件质量和过程改进最为关键的几个问题，从而形成对其过程的改进策略。软件组织只要关注并认真实施一组有限的关键实践活动，就能稳步的改善其全组织的软件过程，使全组织的软件过程能力持续增长。
  • 信息安全等级保护认证
    • 随着国内对网络安全的逐步重视，以及《网络安全法》的出台， 在金融、电力、广电、医疗、教育等行业，主管单位明确要求从业机构的信息系统（APP）要开展等级保护工作。落实到企业，包含等级保护认证和每年的护网活动等。
  • 信息安全管理认证 - ISO27001
    • 信息安全管理实用规则ISO/IEC27001的前身为英国的BS7799标准，该标准由英国标准协会（BSI）于1995年2月提出，并于1995年5月修订而成的。1999年BSI重新修改了该标准。BS7799分为两个部分:BS7799-1，信息安全管理实施规则; BS7799-2，信息安全管理体系规范。第一部分对信息安全管理给出建议，供负责在其组织启动、实施或维护安全的人员使用；第二部分说明了建立、实施和文件化信息安全管理体系（ISMS）的要求，规定了根据独立组织的需要应实施安全控制的要求。

设计模式

在软件开发中，前人对软件系统的设计和开发总结了一些原则和模式， 不管用什么语言做开发，都将对我们系统设计和开发提供指导意义。本文主要将对24种设计模式和7个设计原则进行总结，和具体阐述意义。你可以通过这篇文章设计模式 - Overview 了解整体上的知识点。

知识体系系统性梳理

相关文章

第一步：创建型设计模式

  • 创建型 - 单例模式(Singleton pattern)
    • 单例模式(Singleton pattern): 确保一个类只有一个实例，并提供该实例的全局访问点, 本文介绍6中常用的实现方式
  • 创建型 - 简单工厂(Simple Factory)
    • 简单工厂(Simple Factory)，它把实例化的操作单独放到一个类中，这个类就成为简单工厂类，让简单工厂类来决定应该用哪个具体子类来实例化，这样做能把客户类和具体子类的实现解耦，客户类不再需要知道有哪些子类以及应当实例化哪个子类
  • 创建型 - 工厂方法(Factory Method)
    • 工厂方法(Factory Method)，它定义了一个创建对象的接口，但由子类决定要实例化哪个类。工厂方法把实例化操作推迟到子类
  • 创建型 - 抽象工厂(Abstract Factory)
    • 抽象工厂(Abstract Factory)，抽象工厂模式创建的是对象家族，也就是很多对象而不是一个对象，并且这些对象是相关的，也就是说必须一起创建出来。而工厂方法模式只是用于创建一个对象，这和抽象工厂模式有很大不同
  • 创建型 - 生成器(Builder)
    • 生成器(Builder)，封装一个对象的构造过程，并允许按步骤构造
  • 创建型 - 原型模式(Prototype)
    • 原型模式(Prototype)，使用原型实例指定要创建对象的类型，通过复制这个原型来创建新对象

第二步：结构型设计模式

  • 结构型 - 外观(Facade)
    • 外观模式(Facade pattern)，它提供了一个统一的接口，用来访问子系统中的一群接口，从而让子系统更容易使用
  • 结构型 - 适配器(Adapter)
    • 适配器模式(Adapter pattern): 将一个类的接口, 转换成客户期望的另一个接口。 适配器让原本接口不兼容的类可以合作无间。 对象适配器使用组合, 类适配器使用多重继承
  • 结构型 - 桥接(Bridge)
    • 桥接模式(Bridge pattern): 使用桥接模式通过将实现和抽象放在两个不同的类层次中而使它们可以独立改变
  • 结构型 - 组合(Composite)
    • 组合模式(composite pattern): 允许你将对象组合成树形结构来表现"整体/部分"层次结构. 组合能让客户以一致的方式处理个别对象以及对象组合
  • 结构型 - 装饰(Decorator)
    • 装饰者模式(decorator pattern): 动态地将责任附加到对象上, 若要扩展功能, 装饰者提供了比继承更有弹性的替代方案
  • 结构型 - 享元(Flyweight)
    • 享元模式(Flyweight Pattern): 利用共享的方式来支持大量细粒度的对象，这些对象一部分内部状态是相同的。 它让某个类的一个实例能用来提供许多"虚拟实例"
  • 结构型 - 代理(Proxy)
    • 代理模式(Proxy pattern): 为另一个对象提供一个替身或占位符以控制对这个对象的访问

第三步：行为型设计模式

  • 行为型 - 责任链(Chain Of Responsibility)
    • 责任链模式(Chain of responsibility pattern): 通过责任链模式, 你可以为某个请求创建一个对象链. 每个对象依序检查此请求并对其进行处理或者将它传给链中的下一个对象
  • 行为型 - 策略(Strategy)
    • 策略模式(strategy pattern): 定义了算法族, 分别封闭起来, 让它们之间可以互相替换, 此模式让算法的变化独立于使用算法的客户
  • 行为型 - 模板方法(Template Method)
    • 模板方法模式(Template pattern): 在一个方法中定义一个算法的骨架, 而将一些步骤延迟到子类中. 模板方法使得子类可以在不改变算法结构的情况下, 重新定义算法中的某些步骤
  • 行为型 - 命令模式(Command)
    • 命令模式(Command pattern): 将"请求"封闭成对象, 以便使用不同的请求,队列或者日志来参数化其他对象. 命令模式也支持可撤销的操作
  • 行为型 - 观察者(Observer)
    • 观察者模式(observer pattern): 在对象之间定义一对多的依赖, 这样一来, 当一个对象改变状态, 依赖它的对象都会收到通知, 并自动更新
  • 行为型 - 访问者(Visitor)
    • 访问者模式(visitor pattern): 当你想要为一个对象的组合增加新的能力, 且封装并不重要时, 就使用访问者模式
  • 行为型 - 状态(State)
    • 状态模式(State pattern): 允许对象在内部状态改变时改变它的行为, 对象看起来好象改了它的类
  • 行为型 - 解释器(Interpreter)
    • 解释器模式(Interpreter pattern): 使用解释器模式为语言创建解释器，通常由语言的语法和语法分析来定义
  • 行为型 - 迭代器(Iterator)
    • 迭代器模式(iterator pattern): 提供一种方法顺序访问一个聚合对象中的各个元素, 而又不暴露其内部的表示
  • 行为型 - 中介者(Mediator)
    • 中介者模式(Mediator pattern) : 使用中介者模式来集中相关对象之间复杂的沟通和控制方式
  • 行为型 - 备忘录(Memento)
    • 备忘录模式(Memento pattern): 当你需要让对象返回之前的状态时(例如, 你的用户请求"撤销"), 你使用备忘录模式

架构与系统设计

学习思路

基础到方法论

包括架构的概述，特点，目标，本质以及方法论等

  • 架构 - 架构基础: 特点,本质...
    • 本节总结下架构相关的基础知识：概述，特点，目标，本质...

如何理解架构

理解架构，包括架构的视角，架构的演进，服务化演进，架构的核心要素

  • 架构 - 理解构架的视角
    • 在学习架构时，我认为首先要理清楚架构的视角，因为你所认知的架构和别人所说的架构可能是两码事。对于不同职位的视角是不一样的，比如开发而言他更多的看到的是开发架构；对售前人员，他可能更多的看到的是业务架构；对于运维人员，他看到的可能是运维架构；而对于技术支持和部署人员，他更多的看到的网络和物理架构。
  • 架构 - 理解构架的分层
    • 技术框架（technological Framework）是整个或部分技术系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法。于开发者而言，实际工作从通常采用的是分层模型，由于其重要性，这里独立一个章节，总结经典的七层逻辑架构。
  • 架构 - 理解架构的演进
    • 在学习架构时，第一步不要去学习框架，而是要学习架构的演进。强烈推荐李智慧老师的《大型网站技术架构》，这本书翻起来很快，对构筑你自己的体系很有帮助，本文的内容来源于它，在此基础上拓展了下。
  • 架构 - 理解架构的服务演化
    • Kubernetes、Service Mesh 和 Serverless应该是最近比较火的了，而上文主要从逻辑架构角度分析了架构演进，本文将从服务演化和容器编排化的角度帮你增强对架构演进的认识。
  • 架构 - 理解架构的模式1
    • 架构演进中有很多知识点，总体上可以归结为以下模式，这里说的模式本质是架构中技术点的抽象。强烈推荐李智慧老师的《大型网站技术架构》，本文的内容也是来源于它，在此基础上拓展了下。
  • 架构 - 理解架构的模式2
  • 架构 - 理解架构的核心要素
    • 一般来说软件架构需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素。

架构高并发和高可用

架构高并发和高可用技术点主要包含如下方面。

  • 架构之高并发：缓存
    • 高并发实现的三板斧：缓存，限流和降级。缓存在高并发系统中有者极其广阔的应用，需要重点掌握，本文重点介绍下缓存及其实现。
  • 架构之高并发：限流
    • 每个系统都有服务的上线，所以当流量超过服务极限能力时，系统可能会出现卡死、崩溃的情况，所以就有了降级和限流。限流其实就是：当高并发或者瞬时高并发时，为了保证系统的稳定性、可用性，系统以牺牲部分请求为代价或者延迟处理请求为代价，保证系统整体服务可用。
  • 架构之高并发：降级和熔断
    • 在高并发环境下，服务之间的依赖关系导致调用失败，解决的方式通常是: 限流->熔断->隔离->降级, 其目的是防止雪崩效应。
  • 架构之高可用：负载均衡
    • 负载均衡（Load Balance），意思是将负载（工作任务，访问请求）进行平衡、分摊到多个操作单元（服务器，组件）上进行执行。是解决高性能，单点故障（高可用），扩展性（水平伸缩）的终极解决方案。
  • 架构之高可用：容灾备份,故障转移
    • 容灾技术是系统的高可用性技术的一个组成部分，容灾系统更加强调处理外界环境对系统的影响，特别是灾难性事件对整个IT节点的影响，提供节点级别的系统恢复功能。故障转移（failover），即当活动的服务或应用意外终止时，快速启用冗余或备用的服务器、系统、硬件或者网络接替它们工作。故障恢复是在计划内或计划外中断解决后切换回主站点的过程。

架构的安全

此外还需要关注下架构的安全。

  • 架构 - 保障架构安全
    • 本文对架构安全知识点梳理。

架构参考资料

书籍推荐

F. 架构参考资料：此外还会总结下架构里面比较好的学习资料。

1. 《大型网站技术架构：核心原理与案例分析》

这是比较早，比较系统介绍大型网站技术架构的书，通俗易懂又充满智慧，即便你之前完全没接触过网站开发，通读前几章，也能快速获取到常见的网站技术架构及其应用场景。非常赞。

2. 《亿级流量网站架构核心技术》

相比《大型网站技术架构》的高屋建瓴，开涛的这本《亿级流量网站架构核心技术》则落实到细节，网站架构中常见的各种技术，比如缓存、队列、线程池、代理……，统统都讲到了，而且配有核心代码。甚至连 Nginx 的配置都有！

如果你想在实现大流量网站时找参考技术和代码，这本书最合适啦。

3. 《架构即未来》

这是一本“神书”啦，超越具体技术层面，着重剖析架构问题的根源，帮助我们弄清楚应该以何种方式管理、领导、组织和配置团队。

4. 《分布式服务架构：原理、设计与实战》

这本书全面介绍了分布式服务架构的原理与设计，并结合作者在实施微服务架构过程中的实践经验，总结了保障线上服务健康、可靠的最佳方案，是一本架构级、实战型的重量级著作。

5. 《聊聊架构》

这算是架构方面的一本神书了，从架构的原初谈起，从业务的拆分谈起，谈到架构的目的，架构师的角色，架构师如何将架构落地……强烈推荐。

不过，对于没有架构实践经验的小伙伴来讲，可能会觉得这本书比较虚，概念多，实战少。但如果你有过一两个项目的架构经验，就会深深认同书中追本溯源探讨的架构理念。

6. 《软件架构师的12项修炼》

大多数时候所谓的“技术之玻璃天花板”其实只是缺乏软技能而已。这些技能可以学到，缺乏的知识可以通过决定改变的努力来弥补。

微服务与服务网格TBD

微服务

Spring Cloud

Kubernetes

Service Mesh

产品与团队

技术人通常沉溺于技术的本身，高估了技术本身的价值，而忽视了其它要素的重要性。@pdai

  • 从产品的角度：产品的本身是解决人性上的需求等
  • 从个人的角度：自身成长，身心建设，认知提升，相关理论等
  • 从团队的角度：承认个体的局限性，关注其它角色和要素的重要性等
  • 从生活的角度：与上面几点而言，生活的本身才是最重要的，保持身心健康，去爱你所爱，不虚此生！

个人成长

个人成长相关

  • 知识体系：如何构建自己的知识体系
    • 这个网站区别于其它博客和公众号是期望构建知识体系，构建知识体系帮助了我很大程度上提升了认知效率。偶然看到36氪分享的一篇文章，也是关于如何构建知识体系的，基本和我的做法一致，现在分享给大家。
  • 自我迭代：从复盘中获得自我迭代
    • 在工作学习生活中，一味的埋头苦干是不行的，如何实现快速的自我迭代，一定是复盘 - 对做过的事加以回顾，从中探寻规律、总结经验、提升解决问题的能力！知乎上有一个相关的讨论在新窗口打开open in new window，本文站在个人复盘的角度总结一些经验（复盘最重要的还是自我实践，然后持之以恒，当然首先要对自己诚实）。
  • 如何提问：提问的智慧
    • 平时我们工作学习中都会遇到很多问题，如何更好的提问，从而促进问题的解决呢？问对问题才有会有正确的答案。这里强烈推荐看这篇《提问的智慧》，本文翻译自How To Ask Questions The Smart Way在新窗口打开open in new window，原文在GitHub有几万的赞，足以见得本文被推崇的程度。
  • 问题分析：5W2H分析法
    • 平时遇到问题，如何应用一些分析方法来帮助我们系统性思考呢？5W2H分析法。
  • 人的需求：马斯洛需求模型
    • 人都潜藏着各种需求，作为团队中一员或者团队的管理者，如果能从人核心的需求出发，解决他的底层需求，就能增强团队的满足感。
  • 个人价值：个人价值冰山模型
    • 你的收入是由什么决定呢, 站在理论角度如何提高收入呢？这里分享一篇文章主要从冰山模型谈个人价值、个人回报。
  • 人生效率：如何做好人生效率管理
    • 虽然我也鼓励别人积极学习生活，但是时常也会焦虑，那么如何去调整心态，积极的去面对呢？这里分享一篇 PM熊叔 的文章《如何做好人生效率管理》，一起做好人生效率的管理，一起共勉。
  • 思维模型：查理芒格推荐的100个思维模型
    • 我对查理芒格的《穷查理宝典》印象比较深的一个观点是：在手里拿着一把锤子的人眼中，世界就像一颗钉子。大多数人试图以一种思维模型来解决所有问题，而其思维往往只来自某一专业学科；但你必须要知道各种重要学科的重要理论，才能洞察问题本质。本文标题就不去纠结了，100个思维模式可以供你参考。
  • 年轻心态：张一鸣 - Stay hungry, Stay young
    • 张一鸣在“2016今日头条Bootcamp”上对研发&产品部门应届毕业生发表了题目为“Stay hungry, Stay young”的演讲。多年以后来看，他提的优秀年轻人的五个特质很值得年轻人深思，同样也适合工作老鸟保持年轻的心态。
  • 反内耗：停止心理内耗才能变更强
    • 真正厉害的人，都是“反内耗”体质，只有停止心理内耗，这样才会一步步变强。很多人抱怨开发越来越卷，而实际上多数人的卷来源自己的'内心的卷'(心理上的内耗），本文主要转载自知乎上一个关于人是如何变强的回答，希望能给你一些启发。

产品相关

产品相关

  • 张小龙：微信背后的产品观
    • 之前虎嗅曾发表了“和菜头”写的《张小龙：微信背后的产品观》。那篇文章虽基于张小龙的产品经验分享，其实相当多的内容是来自和菜头本人的理解，现在，虎嗅再根据点点网CEO许朝军的博客内容，把张小龙的现场分享实录呈现给大家。
  • Martin Fowler: 关注成效而非产出
    • 近两年pdai所接触到的项目，很多功能并没有解决用户的痛点，而只是开发设计人员觉得它应该有，这些应该有的背后其实就是Martin Fowler所反对的，他的观点是我们应该关注成效而非产出（用代码量、功能点、还是用户故事） 。本文转载了TW翻译的Martin Fowler的这篇文章，希望能给你带来启发。
  • 产品歪楼：如何做好产品决策中的内部环境分析
    • 很多时候，产品经理在做产品的过程中，发现产品做着做着就歪楼了，然后就开始烂尾。有些时候，你或许经常会像彩霞仙子一样感叹：“我猜中了开头，却没有猜中者结局！”

团队相关

团队相关

  • 华为：软件开发团队如何管理琐碎、突发性任务
    • 如何管理琐碎、突发性任务? 请看华为团队的分享。
  • 张一鸣：做CEO要避免理性的自负
    • “Context，not Control”。 成功的创业者必然会面对公司从小变大的结果。CEO作为创造者与执掌者，需要不断更新自我，及时应对公司发展带来的管理挑战。在源码资本2017年码会上，今日头条创始人CEO张一鸣为码会高低年级的同学分享重量级管理心得：做CEO要避免理性的自负。
  • 美团: 研发团队资源成本优化实践
    • 很多管理者在业务发展的较前期阶段，可能并没有意识到资源成本膨胀所带来的压力。等到业务到了一定规模，拿到机器账单的时候，惊呼“机器怎么这么费钱”，再想立即降低成本，可能已经错过了最佳时机，因为技术本身是一个相对长期的改造过程。资源成本优化宜早不宜迟。本文我们将分享美团到餐研发团队的资源成本优化实践。
  • 哈啰：团队过程管理演进之路
    • 职能团队依据业务领域需要划分为跨职能团队，怎么让团队运转起来？怎么组织跨团队的事情？怎么提升团队的自组织能力？怎么了解团队的效能情况？怎么拉通价值流上的角色？本文为你阐述团队管理的进化、精细化之路。本文主要分享哈啰技术团队的文章。

其它分享

其它分享

  • 陈春花、赵海然：共生型组织四个特征和四重境界
    • 向你推荐关于未来组织架构的可能演进，作为一个技术人提早做好准备是很有必要的。

关于本站点和我

感恩

感恩活着，感谢岁月静好。@pdai

关于我

A. 关于我：如果你我本人以及我是如何构建知识体系等，可以在如下章节中了解。

相关文章

  • 关于 - 我
    • 你的时间花在哪里，你的收获就在哪里。技术只是技术，生活中的一小部分，仅此而已
    • 等在合适的时机会放出我的微信，并且会建学习讨论圈，尽请期待
  • 关于 - 赞赏❤️的用途
    • 感谢各位读者的支持，能感受到每个留言和每一笔赞赏背后的热情❤️，这是我坚持的动力。我特意整理了超过20元的赞赏者和留言（因为无法导出赞赏记录，我是一条条找记录一个字一个字输入的，只能保留一相对靠前的，以示我对赞赏者的敬意；后续每一笔超过20元的赞赏和留言都会持续记录...）
  • 关于 - 如何构建知识体系
    • 本文主要小结下我在构建一个知识体系时的思考
  • 关于 - 如何自我驱动
    • 本文主要介绍我总结这个知识体系所用的工具栈和自我驱动（类似于公司里敏捷开发）

关于本站点：内容，构建和部署

B. 关于本站点：如果你对这个站点感兴趣，可以在如下章节了解，包含排版，搭建，编译，部署，域名，https以及备案等。

相关文章

  • 关于文档 - 文档的内容
    • 你觉的《Java 全栈知识体系》还应该有哪些内容，或者现有的章节中你发现有好的资源也可以推荐，请在这里留言区向我推荐吧
  • 关于 - 网站错误反馈
    • 感谢读者Tony的反馈，现增加一个专门放错误反馈的地方。
  • 关于 - 最新日更更新清单
    • 本文主要记录本站的更新记录, 2021年之前的更新没有记录，2021年一月份开始记录日更清单。
  • 关于文档 - 文档的排版
  • 关于文档 - 文档的搭建
    • 搭建博客有很多选择，平台性的比如: 知名的CSDN, 博客园, 知乎，简书等；自己搭建比如 Hexo, Gitbook, Docisify等等。我有一颗不安分的心，每种我都用过...但是最后的最后我还是选择了将博客逐移至自己搭建的vuepress
  • 关于文档 - 文档的自动编译
    • 文档托管在Github，有几种选择: Github自带的Github Actions，或者插件Travis CI， 或者插件Circle CI；本文简述本站是如何实现自动化编译的
  • 关于文档 - 文档的自动部署
    • 本文主要介绍 当前文档是如何在我自己的服务器自动编译部署的
  • 关于文档 - 文档的域名，HTTPS，备案
    • 本文主要记录 本文档的域名，HTTPS，备案。 文档的域名，HTTPS，备案 这三个步骤不能反，因为存在依赖关系。

关于内容版权

本站点申明如下：

  • 我的初衷？：希望我的总结可以帮助到在后端开发迷茫的IT从业者, 永远相信助人者自助；
  • 非商业用途？：纯个人学习站点，不会用于商业用途；
  • 内容来源？：目前站点内容大约50%内容为原创，50%内容系整合或者转载，我在每篇文章中尽量注明了出处；针对转载或引用的内容，侵删；
  • 可以转载？：遵循行业内知识共享协议CC 4.0下可以注明出处转载；

关于我的读书

TODO，这里会总结以下我读过的觉得有意义的书