凤凰架构-周志明

架构并不是被发明出来的，而是持续演进的结果。

UNIX 的分布式设计哲学

Simplicity of both the interface and the implementation are more
important than any other attributes of the system — including
correctness, consistency, and completeness

保持接口与实现的简单性，比系统的任何其他属性，包括准确性、一致性和完整性，都来得更加重要。

—— Richard P. Gabriel，The Rise of ‘Worse is Better’，1991

原始分布式时代的教训

Just because something can be distributed doesn’t mean it should be
distributed. Trying to make a distributed call act like a local call
always ends in tears

某个功能能够进行分布式，并不意味着它就应该进行分布式，强行追求透明的分布式操作，只会自寻苦果

—— Kyle Brown，IBM Fellow，Beyond Buzzwords: A Brief History of
Microservices Patterns，2016

单体架构（Monolithic）

“单体”只是表明系统中主要的过程调用都是进程内调用，不会发生进程间通信，仅此而已。

单体系统的不足，必须基于软件的性能需求超过了单机，软件的开发人员规模明显超过了“2 Pizza Team”范畴的前提下才有讨论的价值，因此，本文后续讨论中所说的单体，均应该是特指“大型的单体系统”。

SOA 架构（Service-Oriented Architecture）

面向服务的架构是一次具体地、系统性地成功解决分布式服务主要问题的架构模式。

微内核架构

事件驱动架构

经过了三十年的技术进步，信息系统经历了巨石、烟囱、插件、事件、SOA 等的架构模式，应用受架构复杂度的牵绊却是越来越大，已经距离“透明”二字越来越远了，这是否算不自觉间忘记掉了当年的初心？接下来我们所谈论的微服务时代，似乎正是带着这样的自省式的问句而开启的。

微服务架构（Microservices）

微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。

wiki:

What is microservices

Microservices is a software development technique — a variant of the
service-oriented architecture （SOA） structural style.

微服务是一种软件开发技术，是一种 SOA 的变体形式。

—— Wikipedia，Microservices

Microservices and SOA

This common manifestation of SOA has led some microservice advocates
to reject the SOA label entirely, although others consider
microservices to be one form of SOA , perhaps service orientation done
right. Either way, the fact that SOA means such different things means
it’s valuable to have a term that more crisply defines this
architectural style

由于与 SOA 具有一致的表现形式，这让微服务的支持者更加迫切地拒绝再被打上 SOA 的标签，尽管有一些人坚持认为微服务就是 SOA
的一种变体形式，也许从面向服务方面这个方面来说是对的，但无论如何，SOA
与微服务都是两种不同的东西，正因如此，使用一个别的名称来简明地定义这种架构风格就显得更有必要。

—— Martin Fowler / James Lewis，Microservices

微服务时代充满着自由的气息，微服务时代充斥着迷茫的选择。

像 Spring Cloud 这样的胶水式的全家桶工具集，通过一致的接口、声明和配置，进一步屏蔽了源自于具体工具、框架的复杂性，降低了在不同工具、框架之间切换的成本，所以，作为一个普通的服务开发者，微服务架构是友善的。

可是，微服务对架构者是满满的恶意，对架构能力要求已提升到史无前例的程度。

后微服务时代（Cloud Native）

从软件层面独力应对微服务架构问题，发展到软、硬一体，合力应对架构问题的时代，此即为“后微服务时代”。

注册发现、跟踪治理、负载均衡、传输通信等这些问题一定要由软件系统自己来解决吗？

服务网格”（Service Mesh）的“边车代理模式”（Sidecar Proxy）:
这里是引用" />

服务网格将会成为微服务之间通信交互的主流模式，把“选择什么通信协议”、“怎样调度流量”、“如何认证授权”之类的技术问题隔离于程序代码之外，取代今天 Spring Cloud 全家桶中大部分组件的功能，微服务只需要考虑业务本身的逻辑，这才是最理想的Smart Endpoints解决方案

无服务架构（Serverless）

如果说微服务架构是分布式系统这条路的极致，那无服务架构，也许就是“不分布式”的云端系统这条路的起点。

We predict that serverless computing will grow to dominate the future of cloud computing

我们预测无服务将会发展成为未来云计算的主要形式

—— Cloud Programming Simplified: A Berkeley View on Serverless
Computing, 2019

1. 后端设施是指数据库、消息队列、日志、存储，等等这一类用于支撑业务逻辑运行，但本身无业务含义的技术组件，这些后端设施都运行在云中，无服务中称其为“后端即服务”（Backend as a Service，BaaS）。
2. 函数是指业务逻辑代码，这里函数的概念与粒度，都已经很接近于程序编码角度的函数了，其区别是无服务中的函数运行在云端，不必考虑算力问题，不必考虑容量规划（从技术角度可以不考虑，从计费的角度你的钱包够不够用还是要掂量一下的），无服务中称其为“函数即服务”（Function as a Service，FaaS）。

软件开发的未来不会只存在某一种“最先进的”架构风格，多种具针对性的架构风格同时并存，是软件产业更有生命力的形态。

远程服务调用
表示数据，传递数据， 确定方法
REST 设计风格

1. RESTful 的系统(6大原则)
   服务端与客户端分离（Client-Server）
   无状态（Stateless）
   可缓存（Cacheability）
   分层系统（Layered System）：cdn…
   统一接口（Uniform Interface）
   按需代码（Code-On-Demand）
2. 不足与争议
   REST 缺乏对资源进行“部分”和“批量”的处理能力（GraphQL），REST 没有传输可靠性支持（POST Once Exactly）

分布式事务
1.可靠事件队列（Best-Effort Delivery）

2. TCC 事务

SAGA 事务
SAGA 的目的是避免大事务长时间锁定数据库的资源，后来才发展成将一个分布式环境中的大事务分解为一系列本地事务的设计模式

1. 正向恢复（Forward Recovery）：如果 Ti事务提交失败，则一直对 Ti进行重试，直至成功为止（最大努力交付）。这种恢复方式不需要补偿，适用于事务最终都要成功的场景，譬如在别人的银行账号中扣了款，就一定要给别人发货。正向恢复的执行模式为：T1，T2，…，Ti（失败），Ti（重试）…，Ti+1，…，Tn。
2. 反向恢复（Backward Recovery）：如果 Ti事务提交失败，则一直执行 Ci对
   Ti进行补偿，直至成功为止（最大努力交付）。这里要求
   Ci必须（在持续重试后）执行成功。反向恢复的执行模式为：T1，T2，…，Ti（失败），Ci（补偿），…，C2，C1。

奥卡姆剃刀原则

Entities should not be multiplied without necessity

如无必要，勿增实体

—— Occam’s Razor，William of Ockham

1. 尽可能减少单点部件，如果某些单点是无可避免的，则应尽最大限度减少到达单点部件的流量
2. 在能满足需求的前提下，最简单的系统就是最好的系统

1. 客户端缓存
2. 域名解析(DNS Lookup， 世界根域名服务器的 ZONE 文件只有 2MB )
3. 传输链路优化（Transmission Optimization：连接数优化）
   
4. 传输压缩
5. 快速 UDP 网络连接
6. 内容分发网络(CDN)
7. 负载均衡
   
   8.服务端缓存
   
   
   缓存风险： 缓存穿透/缓存击穿/缓存雪崩/缓存污染

1.认证
http WebAuthn
敏感操作需双因子认证
3. 授权

授权方式：授权码模式（Authorization Code），隐式授权模式（Implicit），密码模式（Resource Owner Password Credentials），客户端模式（Client Credentials）
开始进行授权过程以前，第三方应用先要到授权服务器上进行注册，所谓注册，是指向认证服务器提供一个域名地址，然后从授权服务器中获取 ClientID 和 ClientSecret
隐式授权（第三方应用无需服务器）

http://bookstore.icyfenix.cn/#/detail/1， #后面的/detail/1便是 Fragment
密码模式

客户端模式

设备码模式