做微服务架构主要的点

 

• 几个点

服务注册

服务发现

负载均衡

服务网关：唯一入口，实现用户鉴权，动态路由，灰度发布，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展现

 

• 持续交付机制：自动化测试、部署，主要是灰度发布

结合容器