这篇文章上次修改于 1959 天前,可能其部分内容已经发生变化,如有疑问可询问作者。 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实现 + 运行域---配置域,运行域是业务逻辑的执行机构,而配置域是控制机构,负责定制和个性化业务逻辑。 + 先考虑平台化(提前挖掘用户需求,适合千人团队),再考虑中台(上万)
没有评论