Home | 简体中文 | 繁体中文 | 杂文 | Github | 知乎专栏 | Facebook | Linkedin | Youtube | 打赏(Donations) | About
知乎专栏

第 1 章 多维度架构设计

Multi-dimension Architecture

目录

1.1. 什么是多维度架构
1.1.1. 架构与格局
1.1.2. 架构师的大局观
1.1.3. 运维的三重境界
1.2. 多维度架构之网站HTML
1.2.1. 网站的历史演变
1.2.2. 集群(Cluster)
1.2.3. 缓存技术
1.2.4. 网站静态内容出版
1.2.5. 多媒体数据分离
1.2.6. 图片尺寸优化与自动裁剪
1.2.7. 压缩数据传输
1.2.8. SSL
1.2.9. 搜索引擎相关优化
1.2.10. 静态网站繁简转换
1.3. 多维度架构之网络延迟
1.3.1. 中国的大网络环境
1.3.2. 架构设计需要考虑网络延迟
1.3.3. 总结
1.4. 多维度架构之超时时间
1.4.1. 无处不在的超时时间
1.4.2. 流量漏斗
1.4.3. 微服务的超时时间
1.4.4. 容器技术的超时时间
1.4.5. 最后总结
1.5. 多维度架构之会话数
1.5.1. 路由器和防火墙的会话数
1.5.2. 负载均衡设备的会话数
1.5.3. 服务器的会话数
1.5.4. 应用程序的会话数
1.6. 多维度架构之日志
1.6.1. 一次切割日志引发的血案
1.6.2. 日志归档与数据挖掘
1.6.3. 日志中心规划
1.7. 多维度架构之监控
1.7.1. 背景
1.7.2. 概述
1.7.3. 怎样监控
1.7.4. 总结
1.8. 多维度架构之分库分表
1.8.1. 切分策略
1.8.2. 常规操作
1.8.3. 分表需要从业务角度考虑
1.8.4. 最后总结
1.9. 分布式计划任务
1.9.1. 什么是分布式计划任务
1.9.2. 为什么采用分布式计划任务
1.9.3. 何时使用分布式计划任务
1.9.4. 分布式计划任务的部署
1.9.5. 谁来写分布式计划任务
1.9.6. 怎么实现分布式计划任务
1.9.7. 每隔0.5秒执行一次
1.10. 多维度架构之安全
1.10.1. 植入式攻击入侵检测解决方案
1.10.2. Shell 历史记录异地留痕审计与监控
1.10.3. 延伸阅读
1.11. Shell 高级编程
1.11.1. 递归调用
1.11.2. 实现守护进程
1.11.3. 进程间通信
1.12. DevOps实施中你可能遇到的问题
1.12.1. 什么是DevOps?
1.12.2. 为什么会诞生DevOps?
1.12.3. DevOps 虽好,为什么难以普及呢?
1.12.4. 软件工程的历史与进化
1.12.5. 为什么很多企业为什么实施 DevOps 以失败告终?
1.12.6. CI 持续集成不是DevOps
1.12.7. CD 持续交付不是 DevOps
1.12.8. 自动化部署
1.12.9. 收集各部门问题
1.12.10. 收缩技术栈
1.12.11. 被遗忘的数据库
1.12.12. 建立中心仓库
1.12.13. 缓存
1.12.14. 安全
1.13. Kubernetes & Docker 实施中你会遇到的问题
1.13.1. 真的需要容器吗?
1.13.2. 镜像会遇到的问题
1.13.3. 容器会遇到的问题
1.13.4. 运维会遇到的问题
1.13.5. 人员的问题
1.13.6. 当 kubernetes 遇上微服务
1.13.7. 最后总结
1.14. 多维度架构之微服务
1.14.1. 微服务安全吗?
1.14.2. 熔断器解决了什么问题?
1.14.3. 微服务的性能
1.14.4. 多维度架构之微服务拆分
1.14.5. 接口安全
1.15. 多维度架构之远程异地灾备
1.15.1. 背景
1.15.2. 灾备整体解决方案
1.15.3. 数据中心网络
1.15.4. 服务器部署
1.15.5. 软件开发
1.15.6. 自动化运维
1.15.7. 灾备培训和演练
1.15.8. FAQ
1.16. 多维度架构之应用防火墙
1.16.1. 什么是应用防火墙
1.16.2. 功能需求
1.16.3. 简单实现
1.17. 数据库与应用程序间通信
1.17.1. 管道通信
1.17.2. 消息队列
1.17.3. 数据库与外界文件
1.17.4. Socket 方式
1.18. 多维度架构之消息队列
1.18.1. 你是怎样使用消息队列的?
1.18.2. 你是否真正理解了消息队列?
1.18.3. 使用的合理吗?
1.18.4. 是否有必要使用消息队列?
1.18.5. 最后总结
1.19. 多维度架构之Socket连接数
1.19.1. 理解服务器端与客户端
1.19.2. 影响连接的因素有哪些?
1.19.3. 程序怎么写?
1.20. 多维度架构之压力测试
1.20.1. 自动化测试如何破局?
1.20.2. 打破软件自动化测试的格局
1.20.3. 压力测试中存在的问题
1.20.4. 协议测试
1.21. 多维度架构设计之灰度测试方案
1.21.1. 什么是灰度测试?
1.21.2. 解决方案
1.21.3. 工作原理
1.21.4. 管理接口
1.21.5. 使用 Redis 做持久化
1.22. 多维度架构设计之线程池
1.22.1. 并行控制(同步阻塞)
1.22.2. 并行控制(异步非阻塞)
1.22.3. 数据共享
1.22.4. 线程池监控
1.22.5. 线程监控
1.22.6. 线程管理
1.22.7. 线程管理代码

1.1. 什么是多维度架构

1.1.1. 架构与格局

俗话说:烙饼再大,也大不过烙饼的锅。一个人的成就再大,也大不过他的格局。

格局就是具备高视点,宽视野,深洞察,能够跨越时间和空间去看事物,同时不受思维定势的限制。

思维定势又称“习惯性思维”,是指人们按习惯的、比较固定的思路去考虑问题、分析问题,表现为在解决问题过程中作特定方式的加工准备。它阻碍了思维开放性和灵活性,造成思维的僵化和呆板。这使得人们不能灵活运用知识,创造性思维的发展受到阻碍。

人的思维定势会被经历,职业,圈子,财富,出身等很多因素所困扰。

1.1.2. 架构师的大局观

我们从小的教育就是如何拆分问题、解决问题,这样做显然会使复杂的问题变得更容易些。但是这带来一个新问题,我们丧失了如何从宏观角度看问题,分析问题,解决问题,对更大的整体的内在领悟能力。这导致了我们对现有问题提出的解决方案,但无法预计实施该方案后产生的各种后果,为此我们付出了巨大代价。

而我们试图考虑大局的时候,总要在脑子里重新排序,组合哪些拆分出来问题,给它们编组列单。习惯性认为解决了所有微观领域的问题,那么宏观上问题就得到了解决。然而,这种做法是徒劳无益的,就好比试图通过重新拼起来的碎镜子来观察真实的影像。

所以在一段时间后,我们便干脆完全放弃了对整体的关注。

当今的社会,几乎所有的企业情况都是岗位职责清晰,分工明确,员工是企业机器上的一颗螺丝钉,我们在招聘下属的时候也仅仅是用他的一技之长。项目一旦立项,我们就根据项目需求针对性性的招聘,短短半年团队就会膨胀数倍,但效率并不是成正比增长。另一个问题是这个庞大的团队合作起来并不尽人意。结果是 80% 协调的时间,20% 实际工作时间。

很多技术人员埋头在自己的专业领域,更擅长解决自己专业范畴的问题,这样是不对的,技术人员应该培养广泛的兴趣,不仅仅要成为技术全栈,还要涉略艺术等领域。

1.1.3. 运维的三重境界

运维的三重境界你知道吗?

为什么公司在运维上投入很多,高层对运维也足够重视,花了不少钱,但是落地效果不尽人意。

		
发现问题-> 运维救火-> 事后复盘,再发现问题-> 再运维救火-> 再事后复盘,进入了一个死循环。		
		
		

每次救火,领导远程等结果,看着运维这么辛苦,还会发一个表彰报告。

运维的三重境界:器、术、道

  • 器的层面:即工具的安装、配置及使用,包括对操作系统的熟悉程度、各种应用服务器精通程度。比如Linux、Docker、JVM、MySQL、Redis、Ngnix、Elasticsearch、Kubernetes、Prometheus、Grafana……
  • 术的层面:方法论,流程,规范,架构。涉及技术点:负载均衡、埋点、探针、应用监控、故障报警、日志中心、性能调优、链路追踪、故障定位…… DevOps、AIOps……
  • 道的层面:运维体系的建设,最终结果是为产品和运营服务,用户是否满意,运营是否满意,客服是否满意……

80%运维无法突破器这个层面,最终只能做工具的安装和配置。18%有开发经验才能到达“术”的层面,从更高维度审视运维,明白运维的目的。最后2%具备技术背景和产品思维的人才能进入道的层面,明白公司角度要做什么。

所以你会发现运维团队常常是把技术武装到牙齿,你能想到的技术,能装上的都装上,能用的都用上,最终还是开发乱,开发环境乱,测试乱,测试环境乱,生产环境乱,部署乱,部署回撤如家常便饭。

每次出故障第一个发现的不是运维而是客服,是用户遇到问题解决不了,只能800/400客服投诉,客服找运维解决。