微服务是一种架构风格：
- 一系列微小的服务共同组成
- 跑在自己的进程
- 每个服务为独立的业务开发
- 独立部署
- 分布式的管理
- 起点 既有架构的形态
- 终点 好的架构不是设计出来的，而是进化而来的，一直在演进ing
单一应用架构=》垂直应用架构=》分布式服务架构=》流动计算架构
什么不适合微服务？
- 系统中包含很多很多强事务场景
- 业务相对稳定，迭代周期长
- 访问压力不大，可用性要求不高
Organizations which design systems are constrained toproduce designs which are copies of the communication structures of these organizations. 任何组织在设计一套系统(广义概念上的系统)时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。
围绕业务构建团队Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. 设计系统的架构受制于产生这些设计的组织的沟通结构。产品必然是其(人员)组织沟通结构的缩影。 跨部门沟通是非常难的，系统各个模块的接口也反映了它们之间的信息流动和合作方式。
-
单体
-
微服务
- 即时响应性 服务任何时间都要有响应，哪怕挂了
- 可恢复性 也称回弹性，压力大过后压力降下来后状态能够恢复。比如熔断、降级等机制
- 弹性 即伸缩性，无状态服务可以任意扩展
框架最出名的就是 Vert.x Springwebflux RxJava
服务网格与云原生
将服务间的网络通信层及其控制策略下沉到基础设施，就形成了所谓的“服务网格”技术。 通过微服务、容器化、持续交付、Devops等技术，组成了所谓的“元原生”体系。
数据库网格 单元化架构• CellArchitecture • 以单元为组织架构，以单元化部署为调度单位 • 每个单元都是全能的，部署了所有应用，但不是全量的，只有他负责的单元部分的数据 • 通过业务入口设置流量调度器进行流控 微服务架构应用场景 单体与微服务 • 微服务引用在复杂度低的情况下，生产力反而比单体架构低 • 在复杂度高的地方，情况恰恰相反 • 随着复杂度的升高，单体架构的生产力快速下降，而微服务相对平稳 大规模复杂业务系统的架构升级与中台建设 如何实施 微服务架构最佳实践 系统改造 • 功能剥离，数据解耦 • 自然演进，逐步拆分 • 小步快跑，快速迭代 • 灰度发布，谨慎试错 • 提质量线，还技术债 拆分原则 • 高内聚低耦合 • 不同阶段拆分要点不同 扩展立方体 • 特性开关 • 容错设计 自动化 • 自动化测试 • 自动化部署 • 自动化运维 分布式事务 • 幂等/去重/补偿 • 慎用分布式事务 监控体系 • 系统指标 • 业务指标 • 容量规划 • 报警预警 • 运维流程 SOP（StandardOperatingProcedure标准作业程序） • 故障处理 COE（CorrectionOfError 错误处理 ） SpringCloud 微服务相关框架与工具 APM 应用性能监控 • ApacheSkywalking • Pinpoint • Zipkin 监控 • ELK • prometheus + Grafana • MQ + 时序数据库（InfluxDB/ openTSDB） 可观测性 • Tracing • ApacheSkywalking • 听云 • Logging • ELK • Metrics • Prometheus + Grafana 权限控制 核心3A • Authentication 认证Authc • Authorization 授权Authz • Audit 审计 相关框架 • CAS + SSO（CentralAuthenticationService） • TGC TicketGrantingCookie • ST ServiceTicket • JWT/Token • OAuth2.0 • SpringSecurity • ApacheShiro 数据处理 • 分库分表Sharding • 分布式事务DTX • 数据迁移Migration • 数据库集群扩容Scaling • 数据操作审计Audit 网关和通信 • 流量网关与WAF • Nginx • OpenRestry • Kong • 业务网关 • Zuul2 • SCG • Soul • 通信协议 • Http • WebSocket • Mq
