标准化体系建设(下):如何建立基础架构标准化及服务化体系?

架构标准化影响着后续一系列效率和稳定性平台的建设方案。

架构标准化是架构、开发和运维共同的职责。

常见的分布式基础架构组件

微服务的分布式架构下,涉及到的主要基础架构组件

  • 分布式服务化框架,业界开源产品比如 Dubbo、Spring Cloud 这样的框架;
  • 分布式缓存及框架,业界如 Redis、Memcached,框架如 Codis 和 Redis Cluster;
  • 数据库及分布式数据库框架,这两者是密不可分的,数据库如 MySQL、MariaDB 等,中间件如淘宝 TDDL(现在叫 DRDS)、Sharding-JDBC 等。当前非常火热的 TiDB,就直接实现了分布式数据库的功能,不再额外选择中间件框架;
  • 分布式的消息中间件,业界如 Kafka、RabbitMQ、ActiveMQ 以及 RocketMQ 等;
  • 前端接入层部分,如四层负载 LVS,七层负载 Nginx 或 Apache,再比如硬件负载 F5 等。

基础架构组件的选型问题

是自研还是选择开源产品?有这么多的开源产品到底该选哪一个?

按正常的思路,一定是先组织选型调研,然后进行方案验证和对比,最后确认统一的解决方案。

我们以分布式服务化框架为例,我之前遇到的一个实际情况就是,整个大的技术团队选型时以 Java 技术栈为主。

如果技术选型不一致会出现很多问题。

所以,这个时候我们需要做的,就是对基础架构有统一的规划和建设。原则上,每种基础组件只允许一种选型,至少就能满足 90% 甚至更多的应用场景。

比如数据库就只允许使用 MySQL,然后版本统一,同时配套的中间件也必须统一,其它的关系型数据库没有特殊情况坚决不允许使用,如果遇到特殊情况具体分析。

基础架构的服务化

对基础架构组件做了统一标准后,下一步要做的就是服务化

这里以 Redis 缓存为例。

  • 创建和容量申请;
  • 容量的扩容和缩容,新增分片的服务发现及访问路由配置;
  • 运行指标监控,如 QPS、TPS、存储数据数量等等;
  • 主备切换能力等等。

以上这些,假设都依赖 Redis 提供的原生能力来做,基本是不可维护的。所以必须要基于这些原生能力进行封装,结合运维场景,将能力服务化,这样就大大提升了使用方的便利性。

个服务化的过程其实就是 PaaS 化的过程。换言之,如果我们能把基础架构组件服务化完成,我们的 PaaS 平台也就基本成型了。

运维的职责是什么?

可以归纳为两步:第一步是基础架构标准化,第二步是基础架构服务化。

这个时候,运维必须要有意识去做的两件事情。

1.参与制定基础架构标准,并强势地约束。在这里运维作为线上稳定的 Owner,发挥约束作用有可能会比业务架构师这样的角色更为有效。另外,由于历史原因或其他种种因素造成的已有架构标准不统一的问题,是需要开发和运维共同合作去改造的。这里面如何保持良好的协作,制定统一的路线图也是非常重要的。所以这里强制约束是一方面,同时也要提供工具化的手段来支持开发的改造,也就是下面这个动作。

2.基础架构的服务化平台开发,目标是平台自助化,让开发依赖平台的能力自助完成对基础组件的需求,而不是依赖运维的人。这个事情是驱动运维转型和改进的动力,也是运维能够深入了解架构组件细节的有效途径。同时,要注意到,如果不朝着服务化方向发展,运维将始终被拖累在这些基础组件的运维操作上。

总结:

基础架构标准化是影响着后续一系列效率和稳定性平台的建设方案。

对基础架构有统一的规划和建设。原则上,每种基础组件只允许一种选型,至少就能满足 90% 甚至更多的应用场景。

基础架构的服务化,基于redis等等这些组件对原生能力进行封装,结合运维场景,将能力服务化,这样就大大提升了使用方的便利性。基础架构组件服务化完成,我们的 PaaS 平台也就基本成型了。

运维的职责是:第一步是基础架构标准化,第二步是基础架构服务化。

1.参与制定基础架构标准

2.基础架构的服务化平台开发,目标是平台自助化,让开发依赖平台的能力自助完成对基础组件的需求,而不是依赖运维的人。

 

转载于:https://www.cnblogs.com/xiaobao2/p/11246485.html

你可能感兴趣的:(标准化体系建设(下):如何建立基础架构标准化及服务化体系?)