网站源代码下载软件,游戏分类网站怎么做,开源的wordpress,门户网站建设请示云计算带来了业务弹性上的极大优势#xff0c;阿里云数据库高级产品专家时慢从应用架构的变迁#xff0c;客户实战案例#xff0c;业务分析等方面详细介绍POLARDB#xff0c;及如何利用POLARDB设计互联网创新型应用的数据库架构。 应用架构的变迁——为什么我们需要超级MyS…云计算带来了业务弹性上的极大优势阿里云数据库高级产品专家时慢从应用架构的变迁客户实战案例业务分析等方面详细介绍POLARDB及如何利用POLARDB设计互联网创新型应用的数据库架构。 应用架构的变迁——为什么我们需要超级MySQL
POLARDB跟MySQL是100%兼容的有超越MySQL很多倍的性能以及单实例最大100TB的超大存储空间可以理解为阿里自研的超级MySQL。那么我们为什么要打造这样一款超级MySQL呢我们理解这是应用架构进行互联网分布式变迁的必然结果。首先我们需要回顾一下应用架构的变迁的历史从最早的CS架构到BS架构从J2EE到Spring/Struts/Hibernate再到现在的微服务架构经历了很多代的架构转型。从传统应用的业务架构到互联网分布式的应用架构在方方面面都发生了变化。从资源层到数据层中间件应用的发布封装以及应用的框架开发运维的角度都在发生了互联网分布式变迁。 资源层传统应用会使用X86 小机以及存储设备互联网分布式应用在使用公有云私有云混合云等。数据层传统应用会使用OracleDB2等集中化的商业数据库互联网应用使用的是MySQLRedisHBase这样的分布式数据库他们不需要集中化的存储设备。中间件传统应用会使用WebLogicWebSphere等互联网应用在向微服务架构转型中通常会使用SwarmK8SMesos。应用发布封装传统应用会使用JAVA开发并发布成war/ear文件封装再发布到中间件。微服务架构通常会将应用发布成容器的镜像。应用框架传统应用通常会使用SpringStrutshibernate来开发而目前互联网分布式应用更多使用的是SpringCloud, Double, EDAS等微服务架构。开发运维传统应用会使用可控的发布保守的运维新功能上线需要数周甚至数月时间互联网分布式架构更多使用的是DevOps持续集成敏捷快速迭代。
我们理解互联网分布式应用发生这些架构的改变目标都是使业务更加敏捷更加具有弹性能承载来自互联网的高并发压力。在创新架构下业务应用可以通过微服务的方式随时进行横向扩展但压力并不会被处理掉负载会直接透传到数据层面解决了应用弹性的问题反而对数据库产生了更大的挑战。互联网的分布式架构要求数据库更加敏捷拥有更好的弹性以及更低的成本。传统应用中一个应用可能只需要一个数据库作承载但在互联网分布式应用下进行了微服务改造之后一个业务系统可能就需要数十个甚至上百个数据库去承载因此对成本也提出了要求。
实战——阿里云数据库为业务架构变迁做好准备
目前阿里云的数据库形态已经覆盖了互联网中99%的业务场景。关系型数据库包括有MySQLSQL ServerPGPOLARDB。NoSQL产品家族包括RedisMongoDBHBase等。同时具备混合分析型的数据仓库分布式数据库DRDS以及数据库服务于工具DTSDBSCloudDBADMS等。 演进路线
阿里云上提供了这么多的数据库产品在实际应用中该如何进行选择呢我们已经为业务的快速发展和更新迭代做好了准备。这是我们建议的应用架构的演进路线在业务的初期建议选择MySQL来快速构建业务应用。当成长起来之后独立MySQL无法承载更大业务压力的时候可以基于MySQL做读写分离不需要对应用做任何改造。我们进入快速成长期读写分离也无法承载业务需求时可以无缝迁移到POLARDB迁移中不需要对业务系统做任何的更改而且POLARDB的读写分离通过共享存储消除了复制延迟更适合对数据一致性有更高要求的场景。当业务进一步发展壮大期间还可以在POLARDB上做垂直拆分。垂直拆分是指将业务模块垂直拆分到不同数据库实例分到多个独立数据库中去比如分成用户库订单库仓储库等从而用更多的独立数据库联合来应对业务负载的压力。当业务发展到象淘宝这么大的规模和体量就需要采用DRDS进行分布式改造、跨机房多活以及根据业务拆分做单元化改造这正是阿里淘系应用已经走过并行之有效的演进道路。
应用链路的优化——自动读写分离短连接优化
我们使用数据库代理来进行链路访问层的优化。访问数据库的标准模式是直接访问主实例和只读实例。在这种模式下需要在业务层面做读写分离的逻辑拆分。我们提供了代理模式让业务层和数据库层完全解耦。在访问数据库时不需要直接连接数据库实例而是连接对业务完全透明的Proxy它接收到SQL请求后会自动化做读写分离把所有写操作路由到主实例并把读操作负载均衡的路由到只读实例上从而实现对业务透明的自动化读写分离。代理模式除了实现读写分离外还可以进行故障数据库的透明切换。不论是标准模式还是代理模式当主实例发生故障后都可以自动切换到备份的实例上保证数据库的可用性。但在标准模式中切换后业务需要进行数据库重连但通过Proxy业务应用不需要重连感受不到高可用切换。同时代理模式还提供了短连接优化。举例来说如果业务是使用PHP开发它连接数据库就是采用短链接的方式在访问数据库时每次连接都会产生connection使得数据库在处理连接池上不堪重负。Proxy可以将短链接转化成长链接并自主维护连接池。同时代理模式还提供了防暴力破解的功能。比如Proxy可以检测到某个IP不停的尝试重输密码并主动进行屏蔽。
实时分析数据仓库——POLARMPPPOLARDB最佳搭档
数据的处理可以分成数据库生态和大数据生态。数据库生态适合于处理交易订单等数据一致性要求强的场景但在处理能力和处理量级上不会特别大。比如订单量在1TB、2TB级别时还可以使用但数量一旦增长到3TB~5TB时单库的性能就会出现非常大的瓶颈此时复杂的分析查询就会使得数据库不堪重负。通常的做法是采用大数据生态通过ETL或数据复制的方式把在线事务处理产生的数据复制到Hadoop生态中进行数据实时分析。在Hadoop 生态中标准方式是利用MapReduce或Spark来做数据分析但开发人员并不习惯MR或Spark也不喜欢使用Scala语言他们还是习惯于使用SQL。所以在这种模式下经常还要给开发人员准备Hive、Impla等类SQL组件让研发人员仍然可以使用SQL来处理数据。这种方式存在的问题在于在线事务处理和离线数据仓库之间有延迟少则几秒多则几分钟甚至几小时。并且数据实际上存了两份并不经济。
针对这种情况我们提供了POLAR MPP和HybridDB来解决它可以很好的处理数据的写入提供百万级的TPS非常适合用于存储用户的行为、标签、Log日志等。这种模式可以对百亿级的大表做出毫秒级的响应对多表关联做复杂的聚合做多值的子列全文检索。最重要的是它可以和POLARDB共用一份数据极大的缓解了数据库生态和大数据生态中需要存储两份数据并且读写存在延迟的问题。
业务场景分析——互联网创新型应用场景实践
有了云原生数据库作为武器互联网创新型的业务场景应该如何设计呢在讲到创新型业务前先看一下传统的采用MySQL一主N从的架构如何构建数据仓库驱动BI报表实现商务智能。这种架构的问题是需要存储N份数据做数据的同步复制。MySQL 的主从之间要进行数据复制从业务库到分析库也要进行数据复制。
那么采用云原生POLARDB的系统架构应该如何设计呢这之间POLARDB和只读分析库构成了云原生的数据集群由POLAR Store统一进行数据的共享存储。业务应用会把在线的业务写到POLARDB中当POLARDB一主一从的模式不足以应对时可以快速进行扩展扩展成一主两从甚至N从。这种扩展区别于MySQL他提供了敏捷性和业务弹性。如果数据量比较大MySQL只读库的生成可能就需要数个小时的时间。而不管数据量多大在POLARDB生态下创建一个只读库只需要分钟级的时间。并且只需要一份数据就可以通过POLARMPP来驱动业务报表。
云原生架构带来如下的业务收益1. 业务兼容不改应用只要是利用MySQL开发的业务系统可以1. 无缝迁移到POLARDB上。2. 读写分离通过POLARDB一份数据即可实现多个节点的读写分离并且支持分钟级的扩展。如果用MySQL 实现读写分离需要通过数据复制生成多个只读库浪费时间浪费空间。3. 实时分析数据共享在数据仓库和BI分析业务中也只需要一份数据不需要进行数据复制。4. 只读实例共享一份数据由于存储只需要一份带来了更好的性价比以一主五从的架构为例POLARDB的价格要比MySQL低44%。它在提供更强大的性能的基础上提供了更高的性价比。5. 毫秒级的延迟由于主库和从库共享一份数据因此中间只存在毫秒级的延迟。当主节点发生故障时可以保证切换中的零数据丢失。6. Session级读写分离的数据一致性在金融等一致性要求高的业务场景下对读一致性的要求非常高很难容忍秒级甚至毫秒级的数据延迟。利用POLARDB可以实现session内的数据一致性读。7. 按需付费秒级备份在使用MySQL的时候如果预计要使用500GB的容量我们需要买500G的存储空间但实际上数据可能只占了不到100GB但还是需要为500GB的预留容量买单。但POLARDB不需要做空间预留存储按需付费。同时POLARDB通过数据快照可以在秒级实现备份和恢复更利于我们做数据库安全运维带来更多价值。
原文链接 本文为云栖社区原创内容未经允许不得转载。
