微服务粒度的上界是一个2 Pizza Team能够在一个研发周期内完成的全部需求范围
微服务粒度边界
微服务粒度的下界是它至少应满足独立——能够独立发布、独立部署、独立运行与独立测试，内聚——强相关的功能与数据在同一个服务中处理，完备——一个服务包含至少一项业务实体与对应的完整操作。
微服务化的第四个前提条件是复杂性已经成为制约生产力的主要矛盾
以生态自治为目标的自动化，并不是指要达到如此高的自动化程度之后才能开始微服务，只要满足与系统规模及目标相匹配的自动化能力，建设微服务的不同时期，由不同程度的人力去参与运维完全是合情合理的。
微服务化的第三个前提条件是系统应具有以自治为目标的自动化与监控度量能力
微服务化的第二个前提条件是组织中具备一些对微服务有充分理解、有一定实践经验的技术专家
微服务化的第一个前提条件是决策者与执行者都能意识到康威定律在软件设计中的关键作用
指标度量是手段，最终目的是做分析和预警。
基于边车代理的追踪是服务网格的专属方案，也是最理想的分布式追踪模型，它对应用完全透明，无论是日志还是服务本身都不会有任何变化；它与程序语言无关，无论应用采用什么编程语言实现，只要它还是通过网络（HTTP或者gRPC）来访问服务就可以被追踪到；它有自己独立的数据通道，追踪数据通过控制平面上报，避免了追踪对程序通信或者日志归集的依赖和干扰，保证了最佳的精确性。
，基于服务的追踪会比基于日志的追踪消耗更多的资源，也有更强的侵入性，换来的收益是追踪的精确性与稳定性都有所保证，
基于服务的追踪是目前最常见的追踪实现方式，被Zipkin、SkyWalking、Pinpoint等主流追踪系统广泛采用。服务追踪的实现思路是通过某些手段给目标应用注入追踪探针（Probe），针对Java应用一般是通过Java Agent注入。探针在结构上可视为一个寄生在目标服务身上的小型微服务系统，它一般会有自己专用的服务注册、心跳检测等功能，有专门的数据收集协议，把从目标系统中监控到的服务调用信息，通过另外一次独立的HTTP或者RPC请求发送给追踪系统。
基于日志的追踪的思路是将Trace、Span等信息直接输出到应用日志中，然后随着所有节点的日志归集过程汇聚到一起，再从全局日志信息中反推出完整的调用链拓扑关系。
n从实现来看，为每次服务调用记录Trace和Span，并以此构成追踪树结构，听着好像没那么复杂，然而考虑到实际情况，追踪系统在功能性和非功能性上都面临不小的挑战。功能上的挑战来源于服务的异构性，各个服务可能采用不同的程序语言，服务间交互可能采用不同的网络协议，每兼容一种场景，都会增加功能实现方面的工作量。而非功能性的挑战则具体来源于以下这四个方面。
· 低性能损耗：
分布式追踪不能对服务本身产生明显的性能负担。追踪的主要目的之一就是寻找性能缺陷，越慢的服务越是需要追踪，所以工作场景都是性能敏感的地方。
· 对应用透明：
追踪系统通常是运维期才加入的系统，应该尽量以非侵入或者少侵入的方式来实现追踪，对开发人员做到透明化。
· 随应用扩缩：
现代的分布式服务集群都有根据流量压力自动扩缩的能力，这要求当业务系统扩缩时，追踪系统也能自动跟随，不需要运维人员人工参与。
· 持续的监控：
要求追踪系统必须能够7×24小时工作，否则就难以定位到系统偶尔抖动的行为。
与公司实际开发要求相反
避免打印追踪诊断信息。
日志中不要打印方法输入参数、输出结果、方法执行时长之类的调试信息。这个观点是反直觉的
spring security 认证流程
：过滤器→令牌服务→令牌实现
约束条件
非对称加密不能直接用于大量数据的加密。
摘要计算公式
signature = Hash(base64UrlEncode(header) + "." + base64UrlEncode(payload) , secret)
系统设计参考
为了保证信息不被黑客窃取而做客户端加密没有太大意义，对绝大多数的信息系统来说，启用HTTPS可以说是唯一的实际可行的方案。
系统默认规则任务处理
客户端模式是指第三方应用（行文一致考虑，还是继续沿用这个称呼）以自己的名义，向授权服务器申请资源许可。此模式通常用于管理操作或者自动处理类型的场景中。
缓存污染处理模式
Cache Aside模式是指：
· 读数据时，先读缓存，如果没有，再读数据源，然后将数据放入缓存，再响应请求；
· 写数据时，先写数据源，然后失效（而不是更新）掉缓存。
在能满足需求的前提下，最简单的系统就是最好的系统
TCC开发组件建议
基于某些分布式事务中间件（譬如阿里开源的Seata）去完成
使用BASE来达成一致性目的的途径。BASE分别是基本可用性（Basically Available）、柔性事务（Soft State）和最终一致性（Eventually Consistent）的缩写
cap系统设计建议
选择放弃一致性的AP系统是目前设计分布式系统的主流选择，因为P是分布式网络的天然属性，你再不想要也无法丢弃；而A通常是建设分布式的目的，如果可用性随着节点数量增加反而降低的话，很多分布式系统可能就失去了存在的价值，除非银行、证券这些涉及金钱交易的服务，宁可中断也不能出错，否则多数系统是不能容忍节点越多可用性反而越低的。目前大多数NoSQL库和支持分布式的缓存框架都是AP系统
XA事务提交第二阶段
· 提交阶段：
又叫作执行阶段，协调者如果在上一阶段收到所有事务参与者回复的Prepared消息，则先自己在本地持久化事务状态为Commit，然后向所有参与者发送Commit指令，让所有参与者立即执行提交操作；否则，任意一个参与者回复了Non-Prepared消息，或任意一个参与者超时未回复时，协调者将在自己完成事务状态为Abort持久化后，向所有参与者发送Abort指令，让参与者立即执行回滚操作。
XA事务提交第一阶段
· 准备阶段：
又叫作投票阶段，在这一阶段，协调者询问事务的所有参与者是否准备好提交，参与者如果已经准备好提交则回复Prepared，否则回复Non-Prepared。
应对传输可靠性最简单粗暴的做法是把消息再重发一遍。这种简单处理能够成立的前提是服务应具有幂等性（Idempotency），即服务被重复执行多次的效果与执行一次是相等的。
REST风格的系统原则六
6.按需代码（Code-On-Demand）
REST风格的系统原则五
5.统一接口（Uniform Interface）
2022-02-08 18:11:07
REST风格的系统原则四
4.分层系统（Layered System）
2022-02-08 18:10:53
REST风格的系统原则三
3.可缓存（Cacheability）
2022-02-08 18:10:32
REST风格的系统原则二
2.无状态（Stateless）
2022-02-08 18:10:24
REST风格的系统原则一
1.客户端与服务端分离（Client-Server）
架构并不是被发明出来的，而是持续演进的结果。
