1.注册中心实现—-文件路径
eurekaclient续约—-定时心跳renew
2.熔断器— hystrix原理
hystrix command模式，但是侵入性太强，改为aop。
a.数据采集：Hystrix采用的是滑动窗口+分桶的形式来采集数据，使用ConcurrentHashMap 存储
b.行为干预.限流降级：使用信号量，令牌桶,即时干预，延后干预（干预后面一段时间的请求，即open状态会维持一段时间）
c.结果干预，fallback——null或者缺省值
d.快速恢复（—-https://blog.csdn.net/manzhizhen/article/details/79591132 ，https://blog.csdn.net/manzhizhen/article/details/80296655），使用half——open，放请求试用
3.路由ribbon—-iping serverlist

1. 微服务的基石——-持续集成

• 拆之前，要解决合的问题。

• 垂直切分，用户，支付，促销等，api gateway进行合，并且动静分离。治理，发现，日志中心整合，配置中心整合。

• 持续集成，不断的尝试在一起。

• 代码集成—-git
• 单元测试—-方法集成

• 持续集成，持续交付，持续部署，敏捷开发，DevOps什么关系
  

• 敏捷开发是一种开发流程，流程一般很短，2个星期到一个月，甚至一周。如果开发周期过长，就不能达到快速迭代。短时间内提交有价值的东西，才是互联网的目标。
• 持续集成往往指代码的提交，构建和测试。
• 持续交付是只集成好的交付物。如war jar image。
• 持续部署是指将持续交付物，部署在联调环境，或者预发布环境的过程。我们常说的CICD中的CD就是持续发布
• DevOps 不仅仅是CICD，除了技术和流程。还有文化，开发人员也要关心镜像的打包，运维的一部分交给开发来做。避免发布者不知道部署要知道的问题。参考（https://mp.weixin.qq.com/s/mcBdtqBRQbY4D5i6G7o-7g）

1. 微服务的接入层设计—-如nginx，负载均衡。

• 数据中心可用区域的外和中，DNS ，CDN，边界路由等，负载均衡SLB，LVS，Haproxy
• 数据中心的接入层，nginx

• API的聚合
• 服务发现和动态负载均衡
• 动静分离
• 动态资源缓存
• 资源隔离
• 统一鉴权，认证，过滤
• 限流
• 灰度发布和AB测试

1. 微服务拆分

• 微服务拆分以3到5人为一个单元。
• 服务应该是自闭的
• 基础服务，用户，订单等，跟业务关系不大，但是能提供最基础的功能。
• 支持类服务，发短信，支付网关，对业务没关系，但是对业务起到支撑作用
• 核心业务，审批，风控 。这块从两个角度分析，即权衡业务和领域进行整合成新服务：

• 业务——订单，客户管理，产品
• 领域——基础服务，支持服务——核心业务

参考：https://blog.csdn.net/shengtianbanzi_/article/details/80032694

1. 中台

抽取核心业务—-paas平台。参考《http://www.sohu.com/a/301582409_355140》

8.典型的分布式结构

• 要解决的问题

• 横向扩展，架构上的容量问题。，从1亿pv到10亿pv，这里要考虑无状态化
• 纵向扩展，业务扩展问题。业务层次的划分

• 集群

• 一般的集群有master，master会推送路由规则给请求端。
• leader选举模式，增加master的可用性

• 需要分布式中间件

• 负载均衡，LB/LVS,四层，只做链路选择，不做应用层解析。应用层可以用HA，更具URL或者cookie调度流量
• 到达服务层——需要RPC框架。1。同步RPC框架如dubbo，2。异步分布式框架RocketMQ。3。解决静态配置信息的分布式框架。
• 到达数据层——需要解决的问题：1。屏蔽不同数据库的差异2。屏蔽应用层代码对数据分布的感知 如TDDL头都大了或者叫DRDS

• 服务化和分布式化

• 服务化是从业务架构的角度出发，将业务粒度更系，更清晰，边界更清楚，更易于维护—-收敛业务逻辑，通过接口标准化，提供统一的访问方式。
• 分布式化是系统架构层次，先访问什么，再访问什么，一次访问要经过哪些步骤才有最终的结果。
  9 分布式配置框架——配置敏感，且client较少，使用推送模式，达到万级别肯定拉取模式。
• client拉取，定时
• 推送模式，config server，client多时，压力比较大。
• 分布式配置框架，是最简单的管理client机器及相应配置的框架，它也很容易发展成name server和开关系统。
  10 RPC框架

• 管理控制台
• 注册中心，

• php没有启动常驻进程，注册是个麻烦的事情。可以写FPM扩展，而且没法隔离多个php服务。
• 维持长链接，或者轮寻，来保持实例的存活
• 服务发现 —-只关心服务名，不关心谁提供的服务，服务发现就是把当前的实例列表推送给服务调用这。注：以后服务发现有专门的中间件来解决，php这个不是问题了。如lstio的sidecar
• 服务调度和负载均衡，服务调度—-摘除故障节点，负载均衡。
• 统一的sdk封装，code gen ，idl

• 服务提供方
• 服务消费方
• 服务监控
  11.分布式消息框架
• 实时消息 如RocketMQ，kafka

• 异步接偶，语言差异，数据结构差异，更重要的是生产者和消费者的速度差异，空间的解偶

• 最终一致性,时间上的接偶
• 消息的有序性

• 多端消费 ——确认消息是否被消费，容错能力，消息重发

• 延时消息，如电影票15分钟没有支付，则取消。

• 需要定时任务
  12.分布式数据库。

• 分库分表TDDL
• 住被读写分离
  13.分布式文件系统
• TFS，FastDFS，GFS， seaweedfs===副本会存在3个Volume上
• Volume为存储单元，一旦满了，转为只读。每个文件存入一个Volume中。并且返回一个文件名，存储系统不再维护原始文件名和生成文件名的关系。
• 分布式的路由信息石油Master来管理和分配的。
  13.应用的服务化改造
• 应用分层

• 数据访问服务化，不能把Sql散落到各处。即垂直分层，以后分库分表很容易。
• 垂直分层，服务曾，业务逻辑

• 原则：新需求增加时，是否知道需要改哪一层。即分层职责是否清晰，一个层的修改是否会导致其他层的修改。接口返回数据最好是原始类型，否则一层改动，多层受牵连，及接口的收敛。
• 微服务化

• 即水平划分，即每个业务只负责一个功能单元。
  13.分布式的问题

• 集群管理，zookeeper，leader选择（最小节点）。节点的管理。zookeeper使用一个EPHEMERL类型的目录节点每个server调用getChildren方法，然后watch设置为ture，children表话，通知其他server，某太server已经死了。
• 共享锁，选举master，要锁来锁定最终结果的改变
• 队列管理
  14.分布式消息通道

———————————————————————无线化——————————————-

1.无线端的挑战

• app端更多状态，更加可控，减少与后台交互
• 服务端要兼容各个端，如何复用
• 多端登录和多平互动
  2.无线接入层
• 对业务透明，比较轻，不参与业务逻辑，易于维护，如阿里的bff层
• 服务话，插件化
• 高效稳定
  3.端的演进
• 整体来说html5代替不了app
• html5 css 内联
• bigpipe 首屏加载
• cookie压缩，注意符合cookie规范，仅仅能包含ASCII 34-126的可见字符。
• URL 短域名，减少传输，替换解析
• 静态CDN前置
• 快速迭代——模板+数据来实现客户端的迅速迭代

1. 无线链路的优化

• 无线请求合并
• 数据量的大小，pc端，从20kb到80kb增加了100毫秒，无线端而20kb到80kb增加700毫秒
• CDN动态加速
• webp
  5.服务端
• 各端减少重复开发，业务层和展示层分开—-即生成JSOn还是HTML要分开处理。
• MC和V分开，后面M和VC分开。VC交给Node，java只负责M（即数据和业务）
• 业务端的组建化（见后面）

————————————————————-大中台小前台—————————————————————-
1.中台，通过制定标准和机制，把不确定的业务规则和流程通过工业化和市场化的手段确定下来。以减少人与人之间的沟通成本，同时还能最大程度的提升协作效率

• 如商品平台，交易平台，会员平台，营销平台，招商平台。
• 后面依赖PAAS，中间件，研发平台
• 中台的核心—-服务，数据，功能
• 开发态和运行态分离，SPI
• 功能域——-功能组——功能点——-SPI实现
• 运行域—-配置域，运行域是业务逻辑的执行机构，而配置域是控制机构，负责定制和个性化业务逻辑。
• 先考虑平台化（提前挖掘用户需求，适合千人团队），再考虑中台（上万）