day01微服务架构电商系统性能调优篇

---

前言

微服务架构电商系统企业级实战

---

一、day01、微服务架构电商系统性能调优篇

电商系统微服务架构剖析，如何实现系统高并发；

• 单一架构
• 垂直应用架构
• 分布式服务架构
• 流计算架构

商城模块划分

大前端只做SOA的view，数据由服务端传入
面向Dubbo进行调用 核心(注册中心)
服务提供者包括各种微服务
有什么数据穿什么数据
广告，数据库，redis各存一份怎么同步
后台把商品存入数据库，想马上搜索到，搜索走到了solr，搜索引擎库，怎么同步，用同步效果不好，使用异步
服务提供者面向Dubbo注册，前端订阅
cart购物车模块，passport单点登录，seckill秒杀，search
mapper，pojo，redis

统计分析，三方接入，发货，业务中心，soa的架构模式
注册中心，消费者manage和提供者provider，
两个JVM通信通过rpc，是soa的核心
soa的架构方式

服务提供者启动，在容器中运行，main函数启动，不用容器，启动成功之后将自己提供哪些服务，注册给注册中心，consumer根据需求去注册中心订阅服务，注册中心把服务返回给consumer，变化的通知，注册中心使用notify通知consumer，rpc调用跨jvm通过网络进行调用，
Monitor组件监控，一个典型的SOA架构模式的调用方式，Consumerview；providerserver，通信采用RPC。

什么叫RPC，两个角色分别是什么，注册中心

RPC实现原理深入分析
RPC(Remote Procedure Call):远程过程调用，Remote Procedure Call Protocol它是一个计算机通信协议。它允许像调用本地方法一样调用远程服务。由于不在同一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。

RPC服务消费方核心功能实现设计


Consumer的连接管理

Consumer和provider使用一条连接Connect manage：节省时间和资源
provider与数据库不能使用一条连接

商品中心的多线程模型是如何保持高效的

Bussies Thread 通过IOThread 去UserService取数据
阻塞哪个线程？ 如果阻塞到了IO，会全阻塞，因为RPC通信只有一条通道，阻塞的是Bussies Thread。使用Dubbo也是一条连接，

客户端线程->request队列->response队列->唤醒线程
怎么唤醒的？
队列中有很多request，很多response，怎么把这两个对应起来？
如果请求发给Service等了半天，发现没有返回，是不是业务线程一直在阻塞？
request队列多大?response队列多大？
看RPC源码，Dubbo。

队列/线程池(调优，使用资源相同，考量什么耗费资源，，耗费哪些资源，队列耗费的资源就是内存，占用内存多大由请求决定，线程耗费cpu资源)
把请求缓存慢慢处理，做商品的隔离

单队列64线程：对慢线程比较友好，考虑并发问题。
64队列单线程：没有并发问题，不会锁，有可能OOM

1*64对慢请求最友好，与最优压测类似。

Dubbo线程池策略

注册中心的作用及设计分析

注册中心

注册中心本质与设计思考

CAP理论和BASE理论

Base理论：只能同时满足其二不能同时满足三个

Partition tolerance

Avaliability

Consistency

P定死，一定要有，在C和A之间取舍，根据业务具体需求，比如银行必须保持数据一致性C
什么场景保持AP

注册中心选型对比


电商系统日均百万交易系统JVM参数调优企业级实战；
电商系统千万DAU商品中心多线程高并发企业级应用实战；
阿里巴巴开源JVM线上调优工具Arthas企业级应用实战；

总结

讲的没什么大用，也可能我听不懂的原因。