wordpress的网站怎么保存小白如何建设网站

当前位置： 首页 > news >正文

wordpress的网站怎么保存,小白如何建设网站,哪个网站有工笔教程,wordpress源码模板云集电商#xff0c;一家聚焦于社交电商的电商公司#xff0c;专注于‘精选’理念#xff0c;致力于为会员提供超高性价比的全品类精选商品#xff0c;以“批发价”让亿万消费者买到质量可靠的商品。面对近年来外部环境的变化#xff0c;公司对成本控制提出了更高要求一家聚焦于社交电商的电商公司专注于‘精选’理念致力于为会员提供超高性价比的全品类精选商品以“批发价”让亿万消费者买到质量可靠的商品。面对近年来外部环境的变化公司对成本控制提出了更高要求尤其是服务器与人力成本两大领域。当前服务器成本已占据公司总成本的85%以上因此优化成本结构实现高效降本已成为我们当前工作的重中之重。 作为 DBA以更低的成本支撑公司的运营是一项重要的成就对个人而言可以学到很多知识和方法论包括成本分析和评估方法、服务器优化和调整方法、人力成本优化和提升方法等。 业务痛点 在做成本优化前我们需要对自身业务情况及现有痛点有全局的了解。目前很多互联网公司都面临着架构上的痛点云集也不例外。如下图所示最上层的应用层采用微服务架构增加了一个缓存这是因为电商场景会有秒杀需求需要写入很快。 云集主要使用腾讯云上的CDB业务微服务的架构导致数据库实例数很多。针对每一个微服务的数据库实例会有基础的一主一从另外还会有一个用户从库一般一个系统会对应三个数据库实例。 从中间箭头再往下看业务数据库通过Flink、Canal等组件输出到大数据以后会做数据的统计分析生成T0、T1的报表。同时也会将部分大数据分析的数据同步回业务数据库供用户查询形成数据的循环。 右边的话有一个Cloud DB通过OMS到OceanBase的链路比如有一个订单系统业务分了32个实例有个需求是业务需要做整个系统的聚合查询在原来的分库分表架构下无法实现因此同步到一个OceanBase集群里面满足业务查询的需求。以上就是云集现在的整体架构。 那么这个架构存在哪些问题总的来说包括四个方面。 第一数据孤岛。从公司整体角度来看同一个查询理论上只需要执行一次即可但由于业务需求不同无形之中将一份数据在很多存储系统中存储多份。导致请求量放大很多执行多次。而且数据也存放多份导致成本上升。 第二分库分表。分库分表主要依赖于一些中间件而每个中间件有自己的特点和适用场景更为关键的是分库分表中间件带来很多问题需要从业务或运维侧避免: 业务侵入业务需要设计多张表来满足不同的查询需求所有的查询需求需要围绕分区键增加了业务复杂度。聚合查询和关联查询变得困难当出现跨库查询或关联查询时需要业务将数据收集到应用层进行处理变得异常困难。运维变得复杂当需要扩容或缩容时异常痛苦需要大量运维操作进行扩容和数据搬迁 另外当备份和恢复时也会非常复杂和繁琐。 第三运营成本随着微服务进行水平拆分或者垂直拆分导致数据库实例数大幅增加资源成本直线升高另外每个实例的资源并没有得到充分利用CPU 利用率未满20%。如果CPU 超过20%一旦业务波动服务器就难以支撑需要预留一定的硬件资源。 第四数据安全因等保审核要求云集需要满足至少两地三中心的容灾水平这会带来成本的成倍上升。云集在腾讯云上为生产环境做本地备份和远程备份在远处备份过程中会遭遇大量运维问题比如拉取容易失败、拉取耗时过长。另外因为数据量过大需要更高的流量这也导致流量成本大幅上升。 成本优化方案 基于上述架构痛点我们探索了几种成本优化的方案。 业务架构复杂数据流循环和其他环节冗长故障概率较高决定舍弃分库分表架构。在数据治理和数据归档方面归档服务器存储容量有限无法满足需求通过将归档数据转移到OceanBase利用其数据压缩率高的特性在节省存储成本的同时变相扩展容量上限目前无明显瓶颈。整合业务实例在保证服务可用的情况下尽量申请更少的服务器资源增加服务器资源闲时利用率比如电商业务主要在白天运行晚上业务较少的时候就可以生成T0、T1报表数据充分利用资源。考虑使用具备HTAP特性的分布式数据库替代传统数据库将在线和分析的业务集中在一套集群中完成简化数据链路环节降低业务架构复杂度减少运维人力。并且在相同业务负载的情况下发挥分布式数据库高性能的优势使用更少的机器资源优化成本。 上述的成本优化方案面临的阻力有哪些呢 一个新的架构体系需要时间来验证是否能支持现有业务的发展需要在架构替换前期证明它可以支持业务的发展并且说服开发团队增加工作量以支持架构改造、学习和适应新技术是值得的。因此人力和新技术的学习成本是云集架构改造面临的主要阻力。 云集 OceanBase 的成本优化方案 在整个成本优化过程中主要考虑了以下几个原则 稳定性强保证整体业务的稳定和无感知。兼容性高简化新技术和架构的应用降低开发难度减少学习成本。不过度优化避免因过度优化而降低业务的波动能力。 之所以选择 OceanBase 作为数据存储解决方案主要是因为 OceanBase 与 MySQL 的兼容性减少开发工作量和版本的稳定性。OceanBase 的吞吐量和生态系统的支持良好。HTAP 能力和水平扩展能够满足我们的 TP 和 AP 场景的业务需求。 通过引入OceanBase业务由原来的CDB ETL 大数据的架构转变为一套OceanBase集群支撑HTAP业务减少了数据链路的中间环节同一套技术栈同时降低开发工作量通过OceanBase RTO8s、RPO0的高可靠性也满足了等保审核的需求实现了成本上的优化。 总结 本文介绍了基于目前大环境下降本的需要云集的数据库架构以及使用痛点探索了实施降本过程中的方案。最终通过引入OceanBase分布式数据库在满足业务场景的基础上通过其高性能、高压缩、高可靠、HTAP的特性为云集节约了机器、存储、人力运维的成本。近几年的大环境变化使得云集业务流量减少了很多由原来每月的服务器成本峰值达到800多万降为现在不到100万。 这一成本降低的结果是非常显著的。通过技术的优化和适应环境变化成功地实现了成本的大幅度减少。这不仅仅是对云集来说也是对其他企业进行成本优化的一个启示。通过优化技术和适应环境我们可以有效降低成本提高效率获得更好的经济效益。 未来我们也会不断尝试OceanBase新的特性比如最新的4.2.1 LTS版本已经在测试当中希望OceanBase在云集的业务场景里能带来更大的价值。