建设内网网站流程,电子商务网站建设与维护 答案,手机购物软件有哪些,wordpress打电话插件常见的分布式基础架构组件
分布式服务化框架#xff0c;业界开源产品比如 Dubbo、Spring Cloud 这样的框架#xff1b;分布式缓存及框架#xff0c;业界如 Redis、Memcached#xff0c;框架如 Codis 和 Redis Cluster#xff1b;数据库及分布式数据库框架#xff0c;这两…常见的分布式基础架构组件
分布式服务化框架业界开源产品比如 Dubbo、Spring Cloud 这样的框架分布式缓存及框架业界如 Redis、Memcached框架如 Codis 和 Redis Cluster数据库及分布式数据库框架这两者是密不可分的数据库如 MySQL、MariaDB 等中间件如淘宝 TDDL现在叫 DRDS、Sharding-JDBC 等。当前非常火热的 TiDB就直接实现了分布式数据库的功能不再额外选择中间件框架分布式的消息中间件业界如 Kafka、RabbitMQ、ActiveMQ 以及 RocketMQ 等前端接入层部分如四层负载 LVS七层负载 Nginx 或 Apache再比如硬件负载 F5 等。
上面是几类主要的基础架构组件为了便于理解以开源产品举例。但在实际场景中很多公司为了满足业务上的个性化需求会自己研发一些基础组件比如服务化框架、消息中间件等这个情况在有一定技术实力的公司里比较常见。不过大部分情况下会基于这些开源产品做一些封装或局部的改造以适应我们的业务。
基础架构组件的选型问题
大概都会遇到同样的问题是自研还是选择开源产品有这么多的开源产品到底该选哪一个
从单纯的技术选型上来看选择什么语言并没有严格的标准。而且在技术团队中也应该鼓励技术多样性和尝试新技术。不过这里要有个度假设没有统一标准的约束会带来什么问题。
1.开发层面
业务开发同学将大量的精力投入到基础组件和开源产品的研究、研发以及规模化之后的运维上再加上产品形态的不统一导致需要在技术层面的协作上做大量适配工作而且经验还无法互通。
好不容易在一个产品上摸索了很长时间踩了很多坑积累了宝贵的经验结果发现另外一个产品也要经历同样的一个过程积累的经验依然不能互通和传递。
2.运维层面
当我们考虑建设一个统一的效率和稳定体系时发现基础组件不统一这个时候就需要做大量的针对不同组件的适配工作。
比如我们要在发布系统中做服务上下线处理就要针对多个微服务化框架做适配。再举个稳定性上全链路跟踪的例子为了在分布式复杂调用场景下的链路跟踪和问题定位我们会在服务化框架中统一做打点功能这样才不需要侵入业务逻辑。
就这样一个工作如果服务化框架不统一就需要到每个框架里都去开发一遍。不过现实中遇到的实际问题是整个链路就是会有这样那样的情况而串联不起来。
同时还会出现维护投入不足那就必然导致故障频发等一系列问题团队内部也会因为问题定位不清楚而形成扯皮推诿的不良氛围。
所以这个时候我们需要做的就是对基础架构有统一的规划和建设。原则上每种基础组件只允许一种选型至少就能满足 90% 甚至更多的应用场景。
基础架构的服务化
对基础架构组件做了统一标准之后下一步要做的就是服务化。因为这些组件都只提供了简单的维护功能还有很多都是命令行层面的维护这时要做的就是把这些组件提供的维护 API 进行封装以提供更加便捷的运维能力。
以 Redis 缓存为例。
创建和容量申请容量的扩容和缩容新增分片的服务发现及访问路由配置运行指标监控如 QPS、TPS、存储数据数量等等主备切换能力等等。
以上这些假设都依赖 Redis 提供的原生能力来做基本是不可维护的。所以必须要基于这些原生能力进行封装结合运维场景将能力服务化这样就大大提升了使用方的便利性。
要做的事情可以归纳为两步第一步是基础架构标准化第二步是基础架构服务化。
运维必须要有意识去做的两件事情。
参与制定基础架构标准并强势地约束。在这里运维作为线上稳定的 Owner发挥约束作用有可能会比业务架构师这样的角色更为有效。另外由于历史原因或其他种种因素造成的已有架构标准不统一的问题是需要开发和运维共同合作去改造的。这里面如何保持良好的协作制定统一的路线图也是非常重要的。所以这里强制约束是一方面同时也要提供工具化的手段来支持开发的改造也就是下面这个动作。基础架构的服务化平台开发目标是平台自助化让开发依赖平台的能力自助完成对基础组件的需求而不是依赖运维的人。这个事情是驱动运维转型和改进的动力也是运维能够深入了解架构组件细节的有效途径。同时要注意到如果不朝着服务化方向发展运维将始终被拖累在这些基础组件的运维操作上。此文章为2月Day21 学习笔记内容来源于极客时间《赵成的运维体系管理课》推荐该课程。
