分享的主题涉及内容有:
微服务架构，微服务的演变，优缺点
服务发现设计，服务之间的调用，中间件的选择，鉴权，session，熔断，降级，限频….
缓存系统，高效的缓存，避免缓存穿透，预热
分库分表，数据路由，分库分表的索引效率，查询优化，冗余表数据
分布式事务，2pc, 3pc，消息队列解决分布式事务
数据一致性，最终一致性，强一致性
异地多活，业务中取舍，多机房数据同步，数据可靠性
性能监控，metrics监控指标及报表
问题追踪，分布式系统下的问题追踪
自动化测试，单元测试，全局测试
容器部署，自动化部署及灰度发布
我已经把相关的ppt放到社区了，有兴趣的朋友可以看看。
pdf地址: http://xiaorui.cc/micro_service.pdf
ppt在线分享地址: https://www.slideshare.net/rfyiamcool/micro-service-76282335
微服务那些事儿，内容分享简介:
Micro service
1. 微服务那些事⼉ - xiaorui.cc
2. List 微服务 架构层 缓存层 数据层 部署 所谓经验
3. 前世今⽣ ⼀体化架构 >>> soa服务化 >>> 微服务 dish recipe mp social dish recipe mp social ESB dish recipe mp social api gateway discovery db db db db
4. micro service 要微服务的优点 松耦合，代码结构更加清晰 开发者友好，避免老代码包袱. 独立发布、快速迭代 故障隔离 增加重用, 可组合
5. web design (宏) dns Nginx micro service redis mysql Nginx Nginx micro service redis mysql
6. web design (微) etcd s1 api gateway proxy s2proxy s3 engine
7. 协议组合 rpc over tcp; 强约束rpc google grpc apache thrift idl, 协议紧凑, 性能⾼ rpc over http; 不约束rpc http msgpack 协议冗余, 简单, 自定义开发
8. 协议组合 最终: inside; rpc over http msgpack outside; http json
9. 协议{ "output_type": "json", "call_func": "add_dish", "args": [], "kwargs": {}, "uid": “s123”, "login": true, "timeout": 5, "async": false, "ip": "", "sn": "", "origin": “", “app_id”: “”, “timestamp”: “”, “sign”: “” } ... ... { "code": "", "error": "", "res": {} }
10. 服务发现调度的演变 静态配置 智能dns调度 中⼼调度 基于调用⽅构建sdk ALl ==
11. 服务发现之静态配置 s1 s2 get hosts from config.ini; random hosts rpc call 频繁上线 管理麻烦
12. 服务发现之smart dns skydns get domain from dns s2 逃不出的ttl ? 绕脑筋的A记录 注册上报...dns query s1
13. 服务发现之负载均衡 s1 LB s2 s3 s4 单点瓶颈 ? 单点ha ? LB hosts from etcd
14. 服务发现之sdk etcd s2 开发难度不简单 ? 多种语⾔多次开发 ? 注册上报... rpc call watch发现 s1 sdk
15. 那么我们的选择? Etcd s2 注册上报... Rpc Call s1 proxy engine
16. future !!! 降频 熔断 降级
17. 微服务下的session 共享存储 ? 逻辑复用并且调度器uid hash⽅案 ? rpc call user service ? router check user login !
18. 微服务下的接⼝安全 rsa + des 慢, 消息体加密 oauth2 防串改及场景 sign ( jwt ) HMACSHA256( base64UrlEncode(body) + “.”, timestamp + “.”, SECREATE_KEY + “.”, xxx xxx )
19. 缓存层 app redis mysqlinterface redis redis redis redis redisredis redis
20. 缓存层 根据hot及 order by定时服务主动推送热缓存 当数据为空时，只有⼀⼈去db，其他⼈在服务端超时自旋 热数据不采用expire，避免缓存穿透 冷数据采用expire，避免缓存太多 多虚拟节点的⼀致性hash，升级缓存后减少cache miss
21. ⼀级缓存 (被⼲掉) 服务内部mmap + heap实现的ttl dict ⼆级缓存 redis多实例切分 解决单节点做rdb引起swap问题 cpu单核问题 分布式扩展 三级缓存 基于Rocksdb实现类redis数据结构
22. 数据层 服务切了，数据当然也要独立切分 开启多实例，按照业务类型选择不同的disk实例 分库分表⼤势所趋 不使用中间件，自⼰开发sql路由
23. 常见的分库分表 数据过度集中, 不适用blance 时间range id range mode引起扩展不易 key hash … …
24. 场景1 帖⼦id author gtid+user 张三 按照author分库分表，在tiezi_id加⼊分表标志位 or author ! 既想通过author查询，又想通过tiezi_id，如何分库分表?
25. 场景2 tiezi_id author pub_date gtid+user 张三 2017-05-21 按照author分库分表，在tiezi_id加⼊分表标志位 or author ! 查询⽅式 或tid, 或author, 或pub_date, 该如何分库分表? 按照pub_date分库分表, 加⼊tiezi_id 及 author信息 +
26. 场景3 tiezi_id author pub_date update_date gtid+user 张三 2017-05-21 2017-05-30 查询⽅式 (tid, author, pub_date, update_date), 该如何分库分表? 在场景2的基础上, 再加⼊update_date的分表? 如果update_date的需求小于10% ? 那么多表轮询 !!!
27. 场景4 user target_user … 峰云 李宇春 … 解决⽅法, 两组分库分表 查询⽅式 或user, 或target_uer, 该如何分库分表?
28. repair deley redis interface 1 2 repair_man check and set each crud has repair func ! care each except !
29. 事务 ? 事务相关的表尽量在⼀个db库中 强⼀致性, 2pc, 3pc 太耗时… 消息队列最终⼀致性 ⾼效，易理解 读多写少场景用cas
30. begin update amount-100 …. insert (gtid, action, status) commit 消息队列处理事务 s1 begin update amount+100 …. insert (gtid, action, status) commit
31. 分布式事务中的死锁 s1 s2
32. 问题 分布式id 伪自增; 独立库分配auto_id 客户端⽣成; snowflake hash节点不够，扩节点? 预先设立16/ 32 /64 /128 hash值 外键 ? ⼲掉!!! 分布式系统中杜绝外键 !!!
33. metrics 性能监控 app api Elasticsearch grafana redis
34. 调试层 (tracing) gateway自动嵌⼊trace_id 每个逻辑块、服务区⼀个span_id span之间存在⽗⼦调用链关系 根据 trace_id 追踪问题 根据span输出全链路的调用关系及时间轴
35. simple tracing app 日志⽂件 Logstash elasticsearch web ui
36. 业务性能优化 批量io 长连接 缓存 异步io框架 … …
37. deploy 1. unit testing 2. docker image 3. deploy push new version node 4. rem old version node
38. 异地多活 程序随便部署，重点在于 DB 解决idc数据同步问题 备idc部分可脏写及重要只读 不采用mysql主从复制，自开发cs dns层切换数据中⼼
39. – 峰云就她了 “ Q&A ”
END.
