介绍
微服务是细粒度的SOA架构
SOA有什么特征：
- 面向服务
- 松耦合
- 模块化
- 分布式计算
- 平台无关性
- 集中管理
SOA不是单体应用
微服务继承了SOA，区别是真正的分数是、去中心化的，去掉了集中式总线，服务间轻量通信，比SOA更彻底
SOA和微服务对比
微服务对复杂问题域的简化开发，目的是有效的拆分应用，实现敏捷开发、部署和演化
微服务是一种架构模式，提倡将单一应用程序划分为一组小的服务，服务间相互协调、配合，为用户提供最终价值。
服务和服务之间采用轻量级的通信机制（HTTP等），每个服务都围绕具体业务进行构建，能够独立的部署到生产环境、类生产环境等
应避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言，工具进行构建
优势：
- 单一职责：高内聚、松耦合
- 轻量级通信：语言无关、平台无关
- 独立性：开发测试部署独立
- 进程隔离：自治、隔离
劣势：
- 增加系统复杂度
- 离不开DevOps
- 对开发者提出高要求
- 数据一致性的影响
机会：
- 按业务组织充足
- 灰度发布持续集成
威胁：
- 短期成本增加
- 测试、部署的噩梦
- 全能型骨干的缺失
- 数据同步的代价
微服务
不会降低复杂度，反而会增加
运维复杂度增加，离开DevOps，微服务会带来灾难
粒度架构决策
粗粒度不足：
- 复杂度增加，扩展性差
- 不利于扩容和缩容，资源利用率低
- 服务外部耦合度增加
- 容错性差，一个服务处问题会影响较大范围的其他服务
细粒度不足：
- 系统复杂度增加部署和运维难度增加
- 监控复杂
- 问题定位成本增加
决策因素：
- 从业务边界触发，维持微服务业务内部的职责单一原则
- 从敏捷团队管理出发，维持微服务团队内部的地沟通成本
CICD没那么容易实现
分布式CAP架构决策：一致性、可用性、分区宽容性
CAP
一致性：每次读取都是最新的数据或者错误
可用性：请求都得到响应数据，不出现响应错误，但是不保证数据最新
分区容忍性：网络通信不可靠，任意数量的消息丢失或者延迟到达依然提供服务
只有在网络失败时，才会在CA之间做出选择
技术
首先运行时支撑：服务注册/发现、配置中心、网关、负载均衡
服务调用：Dubbo、springCloud
服务容错：超时、熔断、限流、降级、隔离
服务监控：ELK、Skywalking、
部署：Jenkins、k8s、发布机制
消息系统：kafka、rabbit
Rest不是长连接，效率比较低
注册中心：
zookeeper/nacos/eureka
消息系统
kafka更注意性能，用在监控
rabbitMq，
任务调度：Electric Job
日志监控ELK
调用链Skywalking