微服务架构学习

单体架构:
优势:
1)便于开发 (用IDE开发测试即可)
2) 便于测试 (通过单元测试或者浏览器即可)
3)易于部署(打包为单一可执行jar包即可)
不足:
1)复杂性高(代码难以理解,难以修改和重构)
2)交付效率低(难以定位问题,一个地方有问题就需要全量测试)
3)发布频次低
4)伸缩性差(只能整体横向扩展,不能分模块垂直扩展;)
5)可靠性差(一个地方出问题,整个服务都挂了)
6)阻碍技术创新(团队要使用同一的架构和语言,升级和变更技术框架很困难)

微服务架构:
将单体应用拆分为多个高内聚低耦合小型服务,每个小服务运行在独立进程中,有不同的团队开发和维护,服务间采用轻量级通信机制,独立自动部署,可以采用不同语言和部署.
微服务的优势:
1)便于开发(微服务比较小,易于理解,启动时间短,开发效率高)
2)独立部署(单服务的修改不需要协调其他服务)
3)伸缩性强(每个服务都可以横向和纵向扩展,每个服务都可以独立扩容)
4)与组织结构相匹配(每个团队独立维护某些服务)
5)技术异构性(可以使用最适合该服务的技,降低成本)

微服务中的难点:
1)服务拆分(拆分原则:领域模型,组织架构,康威定律,单一指责)(微服务有独立的数据库)(服务之间确定服务边界)
2)数据一致性(可靠性事件模式,补偿模式-sagas模式)
3)服务通讯(通讯技术:RPC/REST/异步消息)
4)服务网管(前后端,身份验证,API Gateway)
5)高可观察(健康检查,集中监控,日志聚合检索,分布式追踪)
6)可靠性(熔断机制,服务降级)

在这里插入图片描述

微服务最佳实践
1)裁剪服务代码模板
2)为微服务分配独立的数据仓库
3)如何对待共享库(日志,通讯等组件)
4)稳定的持续集成,和自动化部署流水线

SOA和微服务区别:
技术栈不同
SOA:ESB SOAP
微服务:RPC/REST/MQ
数据拆分:
SOA:共享数据库
微服务:一服务一数据库
服务粒度:
SOA:粒度比较粗,多个单体组合
微服务:力度更小的服务

微服务的拆分原则和方法:
1)单一职责,高内聚低耦合
2)服务粒度适中(刚开始粒度比较粗,后续粒度会比较细)
3)考虑团队结构
4)以业务模型切入
5)演进式拆分
6)避免环形依赖和双向依赖

微服务拆分步骤
1)分析业务模型(弱耦合的在一起,服务要具有高内聚)
2)确定服务边界(服务要具有单一的上下文)

分布式事务不适用微服务(2pc会有单点故障,因为锁的原因会降低吞吐量)
微服务架构下实现数据一致性
最终一致性 (不同服务节点数据在经过一段时间后最终达到一致性)
可靠性事件模式(消息队列,内部表)(缺点:不能回滚)
补偿模式-sagas模型(支持回滚)

微服务架构技术选型和架构设计
技术选型三要素:
1)保持技术面的广度和深度
2)把握和分析技术选项的优缺点
3)紧密结合项目和团队情况

SpringCloud是一个工具组件集,快速搭建分布式环境的通用模式,基SpringBoot开发,每个组件都是对于一个起步依赖,组件之间可以整合到一起发挥作用.

微服务架构设计
如何进行架构设计
1,深入了解业务,满足功能性需求
2,非功能性需求关注 扩展性,稳定性,可维护性,可伸缩性,高可用,高性能 等
3,坚持KISS原则,防止简单问题复杂化 KISS原则: https://blog.csdn.net/lovejianqiao/article/details/650216

微服务代码脚手架搭建
1,数据访问层代码
2,异常同意处理
3,http日志组件,json解析器

级联故障
解决方案"
舱壁隔离(线程隔离)
超时控制
服务降级
熔断机制

全链路追踪
1)如何串联调用链,快速定位问题
2)如何理清服务依赖关系
3)如何进行各个服务接口的性能分析
4)如何跟踪业务流的处理顺序
全链路追踪解决方案:
Google Dapper
Twitter Zipkin
Spring Cloud Sleuth(是Zipkin的超集)

Spring Cloud Sleuth基本概念
1)Trace(链路):
2)Span(跨度)
3)Annotation(标注):代表四个过程 CS:请求发送 SR请求被接收 SS 服务端响应发送 CR 响应接收

分布式日志检索解决方案ELK
Elasticsearch :日志存储 搜索
LogStash:日志收集(每台服务器安装)
Kibana:可视化界面

参考:https://blog.csdn.net/guduyishuai/article/details/79228306