prchann
prchann
服务并非越小越好，过小的服务也存在弊端 -- 过犹不及。比如，本来可以聚合地调用同个服务，现在不得不分别调用两个服务，这里有较大的时间损耗。 服务大小没有精确的标准，作者描述了一个区间。 * **下限**：它至少应满足 * 独立——能够独立发布、独立部署、独立运行与独立测试， * 内聚——强相关的功能与数据在同一个服务中处理， * 完备——一个服务包含至少一项业务实体与对应的完整操作； * **上限**：（根据邓巴数和康威定律，）一个 2 Pizza Team 能够在一个研发周期内完成的全部需求范围。 疑问： 1. **上限**里的全部需求的数量和工作量，跟项目进度及产品经理的规划有关，并非固定。所以这里也只是一个大概？
单体的主要问题： 1. 隔离性：模块间难以做到物理隔离； 1. 自治性：没法做到单独升级某个模块而不停止其他模块的运行。 微服务能够比较好的解决以上问题，让： 1. 隔离性：通过有效的手段，可做到单服务的故障不影响全局； 1. 有损服务：部分功能不可用，其他功能可继续提供服务； 1. 自治性：独立的新增、升级、下线等。
## 隔离文件：chroot 它类似沙盒，能限制进程的可访问文件。但 UNIX 中存在非文件资源，如用户 ID、IPC 等，chroot 对此类无效。 ## 隔离访问：namespaces 可以理解为一个隔离的空间。该空间有能力隔离多种资源，包括文件、IPC、网络、用户等（不包括资源）。 使用 C 调用 namespaces 接口可参考[《Separation Anxiety: A Tutorial for Isolating Your System with Linux Namespaces》](https://www.toptal.com/linux/separation-anxiety-isolating-your-system-with-linux-namespaces)。 ## 隔离资源：cgroups 资源：指处理器时间、内存、磁盘 I/O...
也称为“云原生时代”。 微服务的到来，也重新抛出了分布式带来的问题。虚拟化、容器及 K8s 能灵活快速地调动硬件。可基于此，在基础设施层面，解决掉这些问题，从而让业务专注于业务本身。比如，服务网格以边车的形式，几乎业务无感知地解决了网络问题（服务注册/发现、熔断、隔离等）。 注：K8s 主要提供资源调度等粗放能力，比较难做到精细化的流量控制能力等。
好处： 1. 简单 1. 快速：无网络损耗 1. 非常适合小型项目 问题： 1. 隔离性差：故障易传递 1. 自治：模块独立发布、升级、停止、扩容、维护 1. 难以技术异构 解决思路： 1. 提升代码可靠性 1. 效果：没法根治。不得不承认代码“出错是必然”，应该换思路为“如何在出错时减少甚至避免造成损失”
* 背景：早期，因单机性能极低， 开始探索分布式，以期多机联合提供更高算力。 * 过程：单机性能提升速度超过解决分布式问题的速度。 * 产出：探索中奠定了 RPC、认证授权、AFS 分布式文件系统等基础。
PC 上使用的 VMWare, Virtual Box, Parallels 等虚拟机软件，是**硬件抽象层虚拟化**吗？谢谢
* VM 带来快速调度机器的能力； * 容器磨平 OS 差异，让 VM 和 应用 兼容，同时让 VM 上的多个应用互不干扰/隔离。
* 云计算时代之前，更换机器的成本高、耗时长，此时选择**改变**基础设施是合理的，因为改变软件比改变硬件更快、更省成本。也即“硬件复用”。 * 云计算来了，它让更换一台“机器/虚拟机”变得随心所欲（多快好省），也即“一次性”使用，用完即丢。 **不改变**基础设施的好处：让机器上运行的软件保持高一致性，易复制、迁移、升级、回滚等。 * 云计算让“不可变基础设施”成为可能。