Fireworks

分布式、微服务 首先明确一个概念，分布式 例如，有一个电商系统，用户 > 订单 > 库存 > 仓储 > 积分 这些业务都在在一个服务中的，耦合极其严重，每次开发、打包、部署、极其繁琐 最主要的一个问题的，如果其中某个服务出现了问题，必然会影响其余服务 分布式通常按业务拆分成多个子系统 每个业务服务子系统部署在单独的机器上 一次下单请求调用多个服务协作共同完成 每个服务只处理...

架构原理图 Dubbo架构层级划分 第一层：service层，接口层，给服务提供者和消费者来实现的 第二层：config层，配置层，主要是对dubbo进行各种配置的 第三层：proxy层，服务代理层，透明生成客户端的stub和服务单的skeleton 第四层：registry层，服务注册层，负责服务的注册与发现 第五层：cluster层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组...

网关的核心功能 动态路由 灰度发布 授权认证 性能监控 系统日志 数据缓存 限流熔断 目前业内的技术方案 Zuul 基于Java开发，核心网关功能都比较简单，但是比如灰度发布、限流、动态路由之类的，很多都要自己做二次开发 高并发能力不强，部署到一些机器上去，还要基于Tomcat来部署，Spring Boot用Tomcat把网关系统跑起来；Java语言开发，可以直接把控源码，可以做二次开发封装各种需...

目前业内的微服务解决方案 通常分为两块 1、以 Dubbo 为主的微服务解决方案 2、以 Spring Cloud 为主的微服务解决方案 这两块微服务解决方案都采用了不同的 注册中心 以 Dubbo 作为服务框架的一般会选择 Zookeeper 为注册中心 以ZK作为服务注册和发现的集群模式 这种多台机器的情况下 ZK 会有2个角色 Leader / Follower 只有 Leader 是可以写...

说明 所谓的灰度发布 假如现在有个服务A 服务A部署在两台机器上 现在对服务A更改了某些功能 但是部署的时候，不会一次把服务A都部署在两台机器上 只会把新代码部署在其中某一台 两台机器，一台是新代码，一台是老代码 灰度发布就是说，按某些权重，请求分发给 不同的机器 比如 新代码 接收 10%的请求，其余 90%给 老代码 验证成功之后，再把另外一台弄成新代码 二次开发 可以针对灰度发布进行二次开发...

分布式系统，拆分为很多个服务之后，他们互相之间要进行调用，平时服务内要优化的一些参数其实不多， 网关 ->（卡住） 订单服务 ->（卡住） wms服务 网关收到的一个http响应，可能就是一个500，internal error Spring Cloud生产优化，系统第一次启动的时候，人家调用你经常会出现timeout 每个服务第一次被请求的时候，他会去初始化一个Ribbon的组件，初...

业内常用方案 （1）数据库唯一索引 （2）基于Redis实现一套幂等性防重框架 对于插入类的操作，一般都是建议大家要在数据库表中设计一些唯一索引 对于扣减库存、累加积分，更新，很难通过数据库唯一索引来保证 基于Redis实现一套接口的防重框架 你得做一个类似spring mvc里的拦截器这样的东西，在这个拦截器里，他会拦截所有的请求， 对所有的请求都会提取请求对应的参数，GET请求、POST请求、...

分布式系统核心的问题，服务框架、注册中心、网关系统、部署架构、超时重试、幂等防重，生产相关的问题 分布式事务 TCC 可靠消息最终一致性 类似TCC事务的，开源框架，ByteTCC，Himly， 阿里开源的分布式事务框架，类似TCC事务，seata来做，这个框架是经历过阿里生产环境大量的考验的一个框架 支持dubbo、spring cloud两种服务框架，都是可以的 可靠消息最终一致性方案，Act...