做微服务架构主要的点
- 几个点
服务注册
服务发现
负载均衡
服务网关：唯一入口，实现用户鉴权，动态路由，灰度发布，A/B测试，负载限流等
配置中心
API管理
集成框架：集成各个微服务组件到统一界面下
分布式事务：TCC，高可用消息服务，最大努力通知
调用链：展示出来方便排查问题
支撑平台：容器云平台
- CAP原理
一致
可用、可靠、可伸缩
分区容忍
三者只能满足其二，比如要做分布式，数据一致性就很难满足，要看具体需求，找到平衡
最终一致性：一段时间后的一致性
- BASE原理
基本可用：保证绝大部分用户的一致性，放弃很小的部分（还是看业务需求，互联网上有些业务是可以的）
软状态/柔性事务：有时可以先把数据缓存在客户端，不同步
最终一致性：一定要在容忍的时间内
- 网关设计
API粒度
API之间不影响
不停机发布API
承载流量：限流，防刷，异步等方法
安全：签名，授权
- 架构演进
单一应用
垂直应用
分布式服务
SOA
微服务
各有各适用场景
- 微服务拆分
案例：很多情况下拆了，下层读写数据还是耦合了
根据业务、领域，系统功能，使用资源，数据边界等拆分
避免先设计数据库
- 几种设计模式
服务代理
服务聚合
服务串联
服务分支
异步消息：通过MQ
共享数据：缓存和数据库
舱壁隔离：分灰度环境，准生产环境，生产环境
- 容错
线程隔离
降级：本地缓存->分布式缓存->库
流量精细化控制
优雅降级：排队，降级，静默降级
限流
熔断
超时
- 框架：springcloud
Euraka：服务注册发现
Ribbon：负载均衡
Feign：http客户端
Hystrix：断路器
Zuul：网关
……
- 数据存储
字段冗余：如订单快照等系统需要
库冗余：主从，主备，集群
同步写
异步写
线下异步写：类主从的模式
- 分库分表
主要是一致性hash
- 保证数据一致性
两段提交：规定好超时时间
TCC：try，confirm，cancel
本地消息表：需要定时轮询消息表，如转账场景
MQ非事务消息：依赖于MQ可靠性
MQ事务消息：适用广泛
- 缓存
CDN
分布式缓存
本地缓存
分布式，主从，主备性能差于本地
redis几乎可替代memcache所有适用场景
案例：
数据量大：分片：hash环集群
峰值明显，异步备份，双写的方式
采用双环的方式保证可靠性，备份环做持久化落盘
- 缓存的一致性
zk实现分布式锁：但是集群不能太大
乐观锁思路+版本号
- 缓存命中率问题
粒度小
数据冷热交换的各种策略：根据实际业务来设计
- 监控范围
组件、存活、方法性能、业务、JVM、服务器性能、报警
WEB展现
- 持续交付机制：自动化测试、部署，主要是灰度发布
结合容器
你的名字
深藏阁楼爱情的钟
古城微笑少年丶
àì夳堔傛蜴生んèń
左手的ㄟ右手
怼烎@
Bertha 。
亦凉
还没有评论，来说两句吧...