左耳听风 - 分布式架构「读书打卡 day 14」

你好！我是 Java 工程师蔡姬，此蔡姬非彼菜鸡！很高兴和大家一起共读陈皓老师的《左耳听风》一书，并在这里分享自己的感悟。

我的读书打卡将会分为两部分——笔记 + 打卡。

• 笔记部分，我会整理在读书过程中感悟比较深的内容，和你一起分享。

• 打卡部分，我会就一个点阐述个人的思考。

话不多说，让我们开始吧！

笔记

分布式系统的架构演进

• 使用分布式系统主要有两个原因：

• 增大系统容量。

• 加强系统可用性。

• 分布式架构存在如下不足：

• 架构设计较为复杂（尤其是分布式事务的架构设计）

• 部署单个服务速度较快，但如果需要同时部署多个服务，则流程会变得复杂。

• 系统吞吐量增大，但响应时间会变长。

• 运维复杂度因服务数量增加而显著增加。

• 架构的复杂性加大了其学习难度。

• 测试和排错的过程变得更加复杂。

• 技术多元化导致运维的复杂度相应增加。

• 管理分布式系统中的服务和调度变得更加困难。

核心使命与关键技术

• 提高系统性能

• 缓存系统

• 负载均衡系统

• 异步调用

• 数据镜像和数据分区

• 提高系统稳定性

• 服务拆分

• 服务冗余

• 限流降级

• 高可用架构

• 高可用运维

• 分布式系统的关键技术

• 服务治理

• 软件架构管理

• DevOps

• 资源调度管理

• 系统架构监控

• 流量控制

分布式系统的纲

• CAP 定理

• 一致性(Consistency)：每个服务节点的每次读取，要么获得最新写入的数据，要么获得一个错误。

• 可用性(Availability)：每个服务节点的每次请求都能获得一个（非错误）响应，但不保证返回的是最新写入的数据。

• 分区容错性(Partition tolerance)：尽管不定量的消息在节点间的网络传输中丢失（或延迟），系统仍然可以继续运行。

• 分布式计算谬误

• 网络是稳定的。

• 网络传输延迟为零。

• 网络的带宽无穷大。

• 网络是安全的。

• 网络的拓扑不会改变。

• 只有一个系统管理员。

• 传输数据的成本为零。

• 整个网络是同构的。

分布式系统典范：PaaS 平台

• 一个好的 PaaS 平台应该具有服务化、分布式、自动化部署、高可用、敏捷及分层开放的特征，并可与 IaaS 平台实现良好的联动。

• PaaS 与传统中间件的区别体现在以下三方面：

• 服务化是 PaaS 的本质，包括重用软件模块、实施服务治理和对外提供能力。

• 分布式是 PaaS 的根本特性，包括多租户隔离、高可用性和服务编排。

• 自动化是 PaaS 的灵魂，包括自动化部署、安装、运维和自动化伸缩调度。

打卡：你觉得分布式架构的核心原理是什么？怎么才能更有效地做好架构设计和工程实施？

在我看来，加强系统可用性并不是使用分布式架构的主要原因，因为单纯地增加冗余也可以加强系统可用性。而且使用分布式架构会引入额外的复杂性，因此，我认为，使用分布式架构的唯一原因就是为了“增大系统容量”。

相对应的，它的核心原理就是分布性，也就是将系统的组件分散部署在多个节点上，从而增加系统容量。

接下来，再谈谈怎么才能更有效地做好架构设计和工程实施这个问题。

架构设计要因情况而异，不要过度设计，可以用单体架构轻松支持的业务就没必要用分布式架构。

在确定要用分布式架构的时候，全局视角很重要，这样可以让你作出更优的决策。

在进行工程实施的时候，细节很重要。没有细节，再高大上的架构都难以落地。

以上便是今日份的笔记和打卡内容。欢迎你在评论区留言，我们一起探讨，共同进步。

我是 Java 工程师蔡姬，期待和伙伴们有更多交流和思维碰撞，明天见！