第1章 服务架构演进史
架构并不是被发明出来的，而是持续演进的结果
2 Pizza Team: 衡量团队大小的量词，指两个Pizza能喂饱的人数，挺有意思
单体系统的真正缺陷不在如何拆分，而在拆分之后的自治与隔离能力上。由于所有代码都运行在同一个进程内，所有模块、方法的调用都无须考虑网络分区、对象复制这些麻烦的事。
但在获得进程内调用的简单和高效的同时，也意味着一部分代码出现了缺陷，将会过度消耗进程空间内的资源，造成的影响也会是全局性、难以隔离的，例如内存泄漏、线程爆炸、阻塞、死循环等问题。如果出现问题的是某些更高层次的公共资源，例如端口号和数据库连接池泄漏，还会影响整台机器，乃至集群中其他单体副本的正常工作。
SOA: Service-Oriented Architecture，面向服务架构，三种代表性的架构模式：
- 烟囱式架构（信息孤岛）
- 微内核架构（插件式架构）
- 事件驱动架构
SOAP协议被边缘化的本质原因：过于严格的规范定义带来过度复杂性
–> ==我的理解==：和OSI7层模型很像，是一种很好的思想，但实际中用到的往往是简化版的，例如5层，TCP/IP协议簇的4层
微服务的概念：
微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言、不同的存储技术，运行在不同的进程之中。服务采用轻量级的通信机制和自动化的部署机制实现通信与运维。
“微服务时代充满着自由的气息，微服务时代充斥着迷茫的选择。”
服务网格(Service Mesh)的边车代理模式(Sidecar Proxy)
在虚拟化场景中的边车指，由系统自动在服务容器（通常是k8s的pod）中注入一个通信代理服务器，以类似中间人攻击的方式进行流量劫持，在应用无感知的情况下接管通信。
这个代理除了实现正常的服务通信外（称为数据平面通信），还接收来自控制器的指令（控制平面通信），根据控制平面中的配置，对数据平面通信的内容进行分析处理，从而实现熔断、认证、度量、监控、负载均衡等各种附加功能。
通过边车代理模式，既不需要在应用层加入额外的处理代码，也提供了几乎不亚于程序代码的精细管理能力。
Serverless的两大内容
- 后端设施(Backend)
指数据库、消息队列、日志、存储等这类用于支撑业务逻辑运行，但本身无业务含义的技术组件
这些后端设施都运行在云中，在serverless中称为Baas(Backend as a Service)
- 函数(Function)
指业务逻辑代码，很接近程序编码角度的函数，区别在于serverless中的函数运行在云端，不必考虑算力和容量规划，称为FaaS(Function ..)
无服务架构确实能降低一些应用的开发和运维成本，例如不需要交互的离线大规模计算，或者Web资讯类网站、小程序、公共API服务、移动应用服务端等契合于无服务架构所擅长的短链接、无状态、适合事件驱动的交互方式。
但另一方面，对于诸如信息管理系统、网络游戏等，或说对具有业务逻辑复杂、依赖服务端状态、响应速度要求较高、需要长链接等特征的应用，至少目前不是那么合适。
如果说微服务架构是分布式系统这条路当前所能做到的极致，那无服务架构，也许就是“不分布式”的云端系统这条路的起点。
软件开发的最大挑战就在于只能在不完备的信息下决定当前要处理的问题。
We can only see a short distance ahead, but we can see plenty there that needs to be done.
–Alan Turing