这篇文章上次修改于 2037 天前，可能其部分内容已经发生变化，如有疑问可询问作者。 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 4. 微服务的基石-----持续集成 + 拆之前，要解决合的问题。 * 垂直切分，用户，支付，促销等，api gateway进行合，并且动静分离。治理，发现，日志中心整合，配置中心整合。 + 持续集成，不断的尝试在一起。 * 代码集成---git * 单元测试---方法集成 + 持续集成，持续交付，持续部署，敏捷开发，DevOps什么关系 ![关系图][1] * 敏捷开发是一种开发流程，流程一般很短，2个星期到一个月，甚至一周。如果开发周期过长，就不能达到快速迭代。短时间内提交有价值的东西，才是互联网的目标。 * 持续集成往往指代码的提交，构建和测试。 * 持续交付是只集成好的交付物。如war jar image。 * 持续部署是指将持续交付物，部署在联调环境，或者预发布环境的过程。我们常说的CICD中的CD就是持续发布 * DevOps 不仅仅是CICD，除了技术和流程。还有文化，开发人员也要关心镜像的打包，运维的一部分交给开发来做。避免发布者不知道部署要知道的问题。参考（https://mp.weixin.qq.com/s/mcBdtqBRQbY4D5i6G7o-7g） 5. 微服务的接入层设计---如nginx，负载均衡。 + 数据中心可用区域的外和中，DNS ，CDN，边界路由等，负载均衡SLB，LVS，Haproxy + 数据中心的接入层，nginx * API的聚合 * 服务发现和动态负载均衡 * 动静分离 * 动态资源缓存 * 资源隔离 * 统一鉴权，认证，过滤 * 限流 * 灰度发布和AB测试 6. 微服务拆分 + 微服务拆分以3到5人为一个单元。 + 服务应该是自闭的 + 基础服务，用户，订单等，跟业务关系不大，但是能提供最基础的功能。 + 支持类服务，发短信，支付网关，对业务没关系，但是对业务起到支撑作用 + 核心业务，审批，风控 。这块从两个角度分析，即权衡业务和领域进行整合成新服务： * 业务----订单，客户管理，产品 * 领域----基础服务，支持服务----核心业务 参考：https://blog.csdn.net/shengtianbanzi_/article/details/80032694 7. 中台 抽取核心业务---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]: http://mmbiz.qpic.cn/mmbiz_png/HO2NI1o25ZaeoKW95NJuVBJuh6Yp0XqbdeJ150AnXYLiaMA55GA0zAGIOTibAZEk4ZIKqeJJlXmjnpRoe9iawp3qA/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1 ----------------------------------------------无线化----------------------------- 1.无线端的挑战 + app端更多状态，更加可控，减少与后台交互 + 服务端要兼容各个端，如何复用 + 多端登录和多平互动 2.无线接入层 + 对业务透明，比较轻，不参与业务逻辑，易于维护，如阿里的bff层 + 服务话，插件化 + 高效稳定 3.端的演进 + 整体来说html5代替不了app + html5 css 内联 + bigpipe 首屏加载 + cookie压缩，注意符合cookie规范，仅仅能包含ASCII 34-126的可见字符。 + URL 短域名，减少传输，替换解析 + 静态CDN前置 + 快速迭代----模板+数据来实现客户端的迅速迭代 4. 无线链路的优化 + 无线请求合并 + 数据量的大小，pc端，从20kb到80kb增加了100毫秒，无线端而20kb到80kb增加700毫秒 + CDN动态加速 + webp 5.服务端 + 各端减少重复开发，业务层和展示层分开---即生成JSOn还是HTML要分开处理。 + MC和V分开，后面M和VC分开。VC交给Node，java只负责M（即数据和业务） + 业务端的组建化（见后面） -----------------------------------------大中台小前台------------------------------------------- 1.中台，通过制定标准和机制，把不确定的业务规则和流程通过工业化和市场化的手段确定下来。以减少人与人之间的沟通成本，同时还能最大程度的提升协作效率 + 如商品平台，交易平台，会员平台，营销平台，招商平台。 + 后面依赖PAAS，中间件，研发平台 + 中台的核心---服务，数据，功能 + 开发态和运行态分离，SPI + 功能域-----功能组----功能点-----SPI实现 + 运行域---配置域，运行域是业务逻辑的执行机构，而配置域是控制机构，负责定制和个性化业务逻辑。 + 先考虑平台化（提前挖掘用户需求，适合千人团队），再考虑中台（上万）
没有评论