易扩展高可用的分布式订单系统架构设计
技术架构方案
技术架构方案第1篇技术架构方案一、背景随着信息化建设的不断深入，我国各行业对技术架构的需求日益增长。
为满足业务发展需求，提高系统稳定性、安全性和可扩展性，本项目将围绕业务目标，结合现有技术资源，制定一套合法合规的技术架构方案。
二、目标1. 满足业务需求，提高系统性能和用户体验。
2. 确保系统稳定、安全、可扩展，降低运维成本。
3. 合法合规，遵循国家和行业标准。
4. 提高开发效率，降低开发成本。
三、技术选型1. 开发语言与框架- 后端：采用Java语言，Spring Boot框架进行开发。
- 前端：采用Vue.js框架，Element UI组件库进行开发。
2. 数据库- 关系型数据库：采用MySQL数据库。
- 非关系型数据库：采用Redis数据库。
3. 中间件- 消息队列：采用RabbitMQ。
- 分布式缓存：采用Redis。
- 分布式服务框架：采用Dubbo。
4. 容器技术- 采用Docker容器技术，实现应用轻量化部署。
5. 云计算- 采用阿里云服务，包括但不限于ECS、RDS、OSS等。
四、系统架构1. 整体架构本方案采用前后端分离的架构模式，后端负责数据处理，前端负责界面展示。
系统架构分为以下几个层次：- 用户层：提供用户操作界面，包括Web端和移动端。
- 前端层：负责接收用户请求，与后端进行数据交互，展示数据。
- 后端层：负责处理业务逻辑，提供数据接口。
- 数据库层：存储系统数据。
- 中间件层：提供消息队列、缓存、分布式服务等支持。
2. 网络架构采用分布式部署，网络架构分为以下三个部分：- 用户访问网络：用户通过互联网访问系统。
- 内部业务网络：内部服务器、数据库、中间件等设备互联。
- 管理网络：用于系统运维管理。
3. 安全架构遵循国家相关法律法规，建立完善的安全架构：- 身份认证：采用用户名密码、手机验证码等方式进行身份认证。
- 权限控制：实现用户、角色、菜单等多维度的权限控制。
- 数据加密：采用SSL加密技术，保证数据传输安全。
软件系统的架构设计方案
软件系统的架构设计方案1000字软件系统的架构设计方案是指在软件开发过程中设计系统的结构、组件和模块之间的关系，以满足业务需求、性能要求和可靠性要求等需求，使得软件系统具有易维护、易扩展、易测试、高可用等优点。
以下是一份软件系统架构设计方案，大体涵盖了架构设计的主要内容和流程。
一、需求分析和功能设计首先使用需求规格说明书对系统需求进行分析和梳理，并定义系统的功能和特性。
通过确定软件需求和功能，可以确立系统的总体架构设计方案，为后续的架构设计提供基础。
二、系统架构设计根据需求分析和功能设计结果，参考相关的架构理论、架构方法和最佳实践等，设计高效、稳定、安全、可靠的软件系统架构。
架构设计的主要内容包括：1、系统结构与分层根据业务流程和需求设计系统的结构与分层，通常分为表现层、应用层、业务逻辑层、数据访问层和数据层等。
2、分布式系统设计对于分布式系统，应尽量采用微服务架构与容器化技术，以实现相对独立的服务模块。
3、数据架构设计数据架构设计主要涉及数据库设计和数据模型设计，要注意数据的存储安全和数据的管理。
4、通信协议设计通信协议设计包括通信数据格式、交互方式、协议规范等，主要是需要确定服务接口和操作流程。
5、系统接口设计系统接口在不同功能模块之间传递数据时，设计通信协议，并通过RPC、REST、Web Services等方式实现接口。
三、系统组件设计系统组件设计是针对系统的模块和组件，参考架构设计方案设计每个模块和部件。
涉及到开发所需技术栈的选择、数据库的类型、缓存机制的选择、消息队列的使用、图像处理等等方面。
要根据需求进行选择，并保证系统的性能、可扩展和可管理性。
四、安全设计安全设计是一个重要的方面，以确保系统的数据和业务流程的安全。
在系统的开发和设计中，应尽可能避免安全漏洞，并采取多个方面的措施，如数据加密，安全加密协议，身份验证和访问控制等。
五、性能设计性能设计是指针对系统的负载、访问量和响应时间进行设计。
指挥平台架构设计方案
指挥平台架构设计方案一、架构设计目标指挥平台架构设计方案的目标是搭建一个高可用、可扩展、易维护的指挥平台，满足指挥平台多样化的需求，支持大规模的数据处理和实时推送，并提供用户友好的界面和操作体验。
二、关键技术和架构选择1. 分布式系统：采用分布式架构能够实现高可用性和可扩展性，并支持水平扩展。
通过将任务分布到不同的节点上进行处理，有效减轻单个节点的负载，提高系统整体性能。
2. 微服务架构：将整个指挥平台拆分成若干个独立部署的微服务，每个微服务负责独立的功能模块，通过API接口进行通信。
这样可以实现模块间的解耦，提高开发和维护的效率。
3. 消息队列：引入消息队列用于实现异步通信和削峰填谷。
当有大量任务需要处理时，可以将任务存入消息队列中，然后由后台的任务处理服务进行消费和处理。
这样可以平衡任务处理的速度和系统的稳定性。
4. 数据存储和缓存：指挥平台需要处理大量的数据，因此需要选择高性能的数据存储和缓存技术。
可以选择关系型数据库和分布式缓存来满足不同的需求。
5. 实时推送：为了实现实时的指挥和监控功能，需要引入WebSocket或者长轮询等技术来实现实时推送。
这样可以将指挥信息实时地推送给用户，提高系统的实时性和响应速度。
三、架构设计方案1. 客户端部分：客户端可以选择使用网页、移动App和桌面程序等不同的方式进行访问。
通过使用RESTful API和Websocket等方式与后台服务进行通信，实现用户界面和业务逻辑的处理。
同时，客户端也需要进行数据的本地缓存和数据的预处理，以提高用户体验和减轻服务器的负载。
2. 后台服务部分：后台服务可以由多个微服务组成，每个微服务负责独立的功能模块，通过API接口进行通信。
具体的微服务包括用户管理服务、权限管理服务、任务调度服务、任务处理服务等。
这些微服务可以通过负载均衡技术进行部署和管理，确保系统的高可用性和可扩展性。
3. 数据存储和缓存部分：可以选择关系型数据库如MySQL来存储用户信息、任务信息等，通过合理的数据分片和索引来提高数据的查询性能。
如何搭建一个高可用的分布式系统
如何搭建一个高可用的分布式系统一、概述随着互联网技术的不断发展，分布式计算成为了解决数据处理和资源利用效率的一种有效方式。
分布式系统在交换数据、计算任务和存储资源时能够提高性能和可靠性，并可应对负载均衡和容错需求。
搭建一个高可用的分布式系统需要考虑多个因素，包括分布式架构、操作系统、软件配置等。
本文将介绍如何设计和实现一个高可用的分布式系统。
二、分布式架构1. 硬件环境要搭建一个高效的分布式系统，首先要考虑硬件环境，包括服务器的数量和类型。
为了实现负载均衡和容错，需要至少两个服务器，这些服务器分布在不同的地理位置，以降低自然灾害等风险。
此外，硬件设置也需要考虑网络的稳定性、容错性等因素。
2. 分布式软件搭建一个分布式系统，需要选择合适的软件。
目前比较经典的分布式架构结构包括Master-Slave模型、Peer-to-Peer模型等。
其中Master-Slave模型，在Master上控制所有的从属节点，处理中央化、任务分配和完成任务之后的后续工作。
而Peer-to-Peer模型，所有节点都能够对彼此进行通信，节点之间具备对等关系，因此各个节点强化彼此之间的平衡并且提升系统的可用性。
三、操作系统选择适合的操作系统也是搭建高效分布式系统的必要因素。
通常，Linux是部署分布式应用最受欢迎的选择，因为它是一种开源操作系统，可定制性很高，并且具有强大的性能和支持。
但是，如果你不熟悉Linux，或者没有Linux的专业知识，那么你可以使用Windows Server 2019等Microsoft的操作系统版本，因为它们易于使用和管理，并为各种应用程序提供支持。
四、软件配置1. 配置java环境Java是一种非常流行的语言，是搭建分布式系统的首选之一。
因此你需要在每个服务器上安装Java JRE或JDK，以便能够运行Java应用程序。
此外，版本问题也要考虑，建议使用稳定版或者社区版本(Oracle或者OpenJDK)。
如何设计可扩展的分布式系统架构
如何设计可扩展的分布式系统架构设计可扩展的分布式系统架构是保证系统能够应对日益增长的负载和需求，实现高可用性和高性能的关键。
在设计分布式系统架构时，需要考虑各种因素包括系统规模、性能需求、可用性需求、数据一致性、容错能力、可维护性等。
下面将从以下几个方面进行介绍如何设计可扩展的分布式系统架构。
1.业务拆分与模块化设计：在设计分布式系统架构时，首先需要将系统按照业务功能进行合理的拆分，将复杂的系统划分成多个相互独立的模块，每个模块负责一部分业务功能。
这种模块化的设计有助于实现横向扩展，即通过增加相同的模块来提高系统性能。
同时，模块化设计也可以通过不同的团队并行开发，提高开发效率。
2.数据分区与负载均衡：将系统中的数据进行分区是设计可扩展分布式系统的常见策略。
通过将数据按照某种规则分散到不同的存储节点中，可以实现数据的分布式存储和查询。
同时，在查询时可以借助负载均衡技术将请求分布到各个存储节点上，达到负载均衡的效果，提高系统的响应性能。
3.异步消息和消息队列：在分布式系统中，通常会涉及到多个模块之间的数据传递和协作。
为了实现解耦和高可扩展性，可以采用异步消息传递的方式。
即将模块间的数据改变通过消息进行通知，接收到消息的模块可进行相应的处理。
同时，引入消息队列可以实现消息的持久化和可靠传递，提高系统的可用性和容错能力。
4.缓存和分布式缓存：缓存是提高系统性能和扩展性的常用策略。
将高频访问的数据缓存在内存中，可以减少磁盘读写和网络传输的开销，从而提高系统的响应性能。
而分布式缓存是将缓存数据分布在多个节点上，减少单个节点的压力，并提高系统对于负载和故障的容错能力。
5.横向扩展与自动伸缩：为了应对不断增长的负载，可以通过横向扩展来提高系统的性能和可扩展性。
即通过增加相同类型的节点来分担负载，实现负载均衡。
同时，为了应对负载波动的情况，可以采用自动伸缩技术来动态地增加或减少系统节点数量，以满足实时的负载需求。
如何设计和编写可扩展的系统架构
如何设计和编写可扩展的系统架构设计和编写可扩展的系统架构是一个复杂而重要的任务，它涉及到多个方面的考虑和决策。
下面我将详细介绍一些设计和编写可扩展系统架构的关键步骤和策略。
1.确定系统需求：在设计可扩展的系统架构前，首先要明确系统的需求。
需求管理的目标是明确系统输入输出要求、功能需求、性能需求等信息，这将对后续的设计决策产生重要影响。
2.分析系统模块：将系统分解为若干独立的模块，每个模块负责不同的功能。
分析每个模块的职责和关系，识别出系统中重要的模块和耦合度高的模块。
3.制定模块间的通信协议：在设计可扩展的系统架构时，需要明确模块间的通信方式和协议。
常见的通信方式包括基于消息队列、远程过程调用、RESTful API等。
选择合适的通信方式取决于系统的需求和规模。
4.利用服务化架构：服务化架构是将系统拆分为一些独立的服务，每个服务具有独立的部署和扩展能力。
通过服务化架构可以实现系统的解耦和灵活性，利于系统的可扩展性。
常见的服务化架构包括微服务架构和面向服务架构（SOA）。
5.采用水平扩展策略：水平扩展是通过增加更多的计算节点来提高系统的处理能力。
这种扩展策略通常是利用容器化技术和云计算平台，使系统能够快速、灵活地增加/减少计算资源。
6.实现负载均衡机制：在设计可扩展系统架构时，负载均衡是非常重要的一环。
负载均衡机制可以将请求均匀地分发到不同的计算节点上，以避免单一节点的过载。
常用的负载均衡策略包括轮询、权重、哈希等。
7.引入缓存机制：引入缓存机制是提高系统性能的一种常见策略。
通过将一些经常访问的数据缓存在内存中，可以减少对数据库或其他存储系统的访问次数，从而提高整个系统的吞吐量和响应时间。
8.引入异步处理：引入异步处理机制可以将一些耗时的操作放入消息队列或任务队列中，并由后台线程异步处理。
这样可以避免阻塞主线程，提高系统的并发处理能力和可扩展性。
9.预留扩展接口：在设计系统架构时，要考虑到未来可能的业务发展和需求变化。
定制平台架构设计方案
定制平台架构设计方案定制平台架构设计方案随着定制市场的迅速发展和用户个性化需求的日益增长，建立一个灵活高效的定制平台成为了众多企业的共同目标。
在构建定制平台的架构设计方案时，应该考虑到以下几个关键因素。
首先是可扩展性。
由于定制平台需要支持大量不同类型的定制需求，所以系统架构应该具有很大的可扩展性。
可以采用微服务架构，将不同功能模块拆分成独立的服务，每个服务可以独立部署和扩展。
这种架构可以更好地应对系统的变化和用户的增长。
同时，使用容器化技术如Docker和Kubernetes可以实现快速部署和水平扩展。
其次是高可用性和负载均衡。
定制平台的稳定性对用户体验至关重要。
为了提高系统的可用性，可以使用负载均衡技术将用户请求分发到多个服务器上，避免单点故障和过载。
同时，可以使用分布式缓存来降低数据库和应用服务器的负载，提高系统性能。
另外，安全性也是定制平台架构设计的重要考虑因素。
由于定制平台涉及到用户的个人信息和支付数据，因此必须保证数据的安全性和隐私保护。
可以采用多层次的安全策略，包括访问控制、数据加密、安全监控和漏洞扫描等。
同时，对于用户提交的定制需求也要进行严格的合法性验证和安全性评估。
此外，智能化是未来定制平台发展的趋势，因此在架构设计中应该充分考虑人工智能和数据分析的应用。
可以使用机器学习算法来分析用户的历史行为和偏好，为用户提供个性化的推荐和定制建议。
同时，定制平台也可以通过分析用户数据来改进产品设计和用户体验。
最后，架构设计方案还应该考虑到系统的易用性和可维护性。
为了提高开发效率和降低维护成本，可以采用模块化开发和组件化设计。
同时，引入自动化测试和持续集成工具可以提高系统的稳定性和质量。
综上所述，建立一个灵活高效的定制平台需要考虑到可扩展性、高可用性、安全性、智能化以及易用性和可维护性等方面的需求。
合理的架构设计方案可以为企业提供稳定可靠的定制服务，满足用户的个性化需求，迎接未来的挑战。
后端系统架构设计实现高性能可扩展的后端系统
后端系统架构设计实现高性能可扩展的后端系统一、概述在当今互联网时代，后端系统的架构设计变得尤为重要。
一个高性能可扩展的后端系统能够有效处理大量的请求，保证系统的稳定性、可靠性和可扩展性。
本文将介绍如何进行后端系统架构设计并实现高性能可扩展的系统。
二、系统设计原则1. 分布式架构：通过将系统拆分为多个独立的子系统或服务，实现系统的分布式部署和水平扩展，提高系统整体的处理能力。
2. 异步消息队列：采用消息队列来解耦各个模块之间的依赖关系，提高系统的响应速度和并发处理能力。
3. 缓存机制：合理使用缓存能够降低数据库的读写压力，提高数据的访问速度和系统的响应能力。
4. 弹性设计：通过自动扩展和负载均衡等机制，根据实际的请求量和负载情况，动态调整系统的资源分配和服务数量，提高系统的可用性和性能。
5. 安全防护：在系统设计过程中考虑安全性，采用合适的防火墙、加密和认证等机制，保证数据的安全性和系统的稳定性。
三、系统架构设计1. 服务模块划分：根据业务需求和功能划分，将系统划分为多个独立的服务模块，每个模块负责特定的功能实现。
2. 分布式部署：将各个服务模块部署在不同的服务器或容器中，通过负载均衡器将请求均衡地分发到各个模块，提高系统的并发处理能力。
3. 异步消息队列：在服务模块之间引入消息队列，解耦模块之间的依赖关系。
当一个模块处理完数据后，将结果通过消息队列发送给下一个模块进行处理，实现异步化处理。
4. 数据库设计：根据业务需求选择合适的数据库类型，通过数据库的读写分离、分库分表等方式提高数据库的处理能力和容量。
5. 缓存策略：使用合适的缓存技术，将常用的数据缓存到内存中，减少数据库的读取次数，提高系统的响应速度。
6. 弹性设计：采用自动扩展机制，根据实际的请求量和负载情况，自动增加或减少系统的资源分配和服务数量，保证系统的可用性和性能。
四、系统实现1. 技术选型：选择合适的编程语言、开发框架和数据库等技术栈，根据业务需求和团队实际情况进行综合考虑。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
易扩展高可用的分布式订单系统架构设计目录摘要 (4)一、简介 (5)二、业界现状 (6)三、系统架构 (8)3.1、交易单元 (9)3.2、订单号 (9)3.3、路由信息表 (10)3.4、代理服务 (11)3.5、交易单元 (11)3.6、事务 (12)3.7、订单重试 (13)3.8、健康度检查服务 (13)四、订单流程 (13)4.1、创建订单 (14)4.2、更新订单 (15)4.3、查询订单 (15)五、架构特性 (16)5.1、线性扩容 (16)5.2、故障压缩 (16)5.3、差异服务 (16)5.4、冷热分离 (17)5.5、灰度控制 (17)5.6、热点均衡 (17)六、备份、容灾和恢复 (17)6.1、备份 (17)6.2、数据一致性 (18)6.3、容灾 (18)七、架构缺点及改进 (18)八、总结 (19)摘要伴随着移动互联网的高速发展、中国第三方支付的快速增长，以及丰富的移动支付产品，深刻改变和培育了中国人民的无现金生活方式，也极大的推进了整个社会经济的发展。
对于支付宝和微信支付这样的国民应用，海量交易带来的系统可用性问题成了关乎国计民生的问题。
作者在2016 年到2018 年有幸参与了微信支付的核心系统的部分开发和改进，也切实感受到支付系统可用性关乎每个产品使用者的产品体验。
支付宝作为国内的另一个电商和支付巨头，他们走出一条自研高可用分布式存储系统的道路，在存储层应对了海量的电商交易和双11 交易海啸的冲击，作者对于支付宝如何解决无状态服务的可用性工作不太了解。
本文结合作者在微信支付参与的核心订单系统的可用性治理的相关项目的经验，思考和总结海量交易所带来的扩容、成本、容灾和灰度等问题及解决方案，提出了一种基于MySQL 单机存储引擎，业务和存储强耦的易扩展、高可用的分布式订单系统方案。
本文主要讲述了基于交易单元构建的高可用分布式订单存储系统，交易单元是由无状态服务和有状态存储服务组成的交易单元架构的基本单元，通过交易单元可以实现线性扩缩容的能力；在下单时通过订单重试的操作可以允许一次下单重试更换到可用的交易单元，这样可以应对少数交易单元不可用带来的下单不可用问题；同时基于交易单元的架构也带来了冷热分离、故障压缩、差异服务、热点均衡和灰度控制的能力。
基于交易单元化的架构虽然带来很多优点，但同时也造成业务和存储强耦合问题，另外业务开发人员在开发时也需要了解整体架构而不能更加专注业务逻辑，让真正专业的架构师在架构层面进行脱离业务的可用性治理。
关键词- 订单系统、高可用、易扩展、分布式、订单重试、交易单元、海量存储一、简介随着移动支付的飞速发展，移动支付用户量持续增加，移动支付已悄无声息的融入到国民的生活并且产生重要的作用。
在支付系统中，一笔交易往往需要多个相关系统的协作完成，其中包括支付产品系统、订单交易系统、风控系统、支付系统、账号系统、商户系统、账户系统和清结算系统等等。
在一个交易系统中一笔交易是通过一笔订单进行标识的，订单系统需要提供创建订单、支付订单、查询订单、关闭订单和订单退款的能力。
订单系统作为其它系统的依赖系统，它的可用性将直接影响整个交易系统的可用性。
交易系统的可用性将直接影响用户的交易体验和整个品牌的口碑。
传统的银行都是基于大型的商业服务器和正版授权的数据库软件构建自己的交易系统，互联网有别于传统银行，往往是采用小型廉价的商业服务器和开源的数据库软件构建自己的交易系统。
另外传统银行的交易系统是集中式的，而互联网企业多采用分布式系统构建自己的系统，这样对数据的一致性、灾备、可用性提出更高的要求。
对于大型企业或者第三方数据库公司，它们会研发一些自己的分布式数据库存储，例如OceanBase、TiDB 等。
但是很多企业还是会采用开源的MySQL 作为自己的数据库系统，一种基于MySQL 实现的易扩展、高可用支持海量存储的订单交易系统对于一个企业也是一种很好的方案选择。
本文会讨论一种基于MySQL 构建的海量订单交易系统，高可用和易扩展作为整个系统两个主要特征。
为了达到整个系统的高可用，可用性主要包含三种改进：•通过使用DBProxy 来进行数据库的快速切换解决存储不可用。
•通过交易单元化进行物理隔离防止单存储故障导致的不可用扩散。
•在系统顶层通过订单重试来降低逻辑服务和存储不可用带来的影响。
为了解决系统的容量，主要通过交易单元的水平扩展来扩充整个系统的容量，同时交易单元化的结构可以很好的解决数据冷热分离的问题。
在系统的垂直方向整个系统主要分为代理层、逻辑服务层和存储层；系统在水平方向是由众多物理隔离的交易单元组成的，一个交易单元包含了对应的逻辑服务和存储，同时交易单元也是水平扩展的基本单位。
本文主要先描述整个系统的整体架构，接下来会描述传统架构中存在问题并提出对应的解决方案，然后会讨论整个架构对可用性和易扩展的实现细节以及交易单元化架构带来的优点和缺点。
二、业界现状交易系统的可用性主要分为无状态服务的可用性和有状态存储的可用性，无状态服务的可用性相比更容易解决，而有状态存储服务的可用性则成为整个交易系统的核心瓶颈。
为了解决有状态存储服务的可用性，业界也研发了很多的金融级分布式系统存储方案。
例如Google 的Bigtable、MegaStore 和Spanner；Facebook 的MyRocks；阿里的OceanBase 和X-Engine；腾讯的TDSQL；PingCap 的TiDB。
这里的存储主要分为两个大的方向：基于关系型数据库构造建分布式关系型存储系统和基于NoSQL 构建的分布式存储系统。
分布式关系型存储系统如OceanBase、MyRocks 和TDSQL 等；分布式NoSQL 存储系统如：Spanner、X-Engine 和TiDB 等。
近代互联网时代，Google 的存储技术是整个互联网行业的技术标杆，其发表的GFS、Bigtable 和Spanner 等一些列技术成果，奠定了近几十年的存储发展方向。
其存储系统也经历Bigtable、MegaStore 到Spanner 的演化，并且Spanner 是第一个把数据分布在全球范围内的系统，并且支持外部一致性的分布式事务。
不管是在存储的理论研究和技术实现，Google 都是这个时代的拓荒者。
Facebook 作为一家技术实力同样强劲的互联网厂商，MyRocks 是Facebook 开发的一款基于RocksDB 的开源MySQL 存储引擎，并且已经稳定支撑Facebook 的海量业务，并作为Facebook 的MySQL 的主分支。
阿里作为中国电商的代表性公司每天都会面临海量的交易，虽然海量交易代表业务的快速增长，但也会对整个交易系统的可用性、扩展性、一致性、性能等提出了更高的要求。
在中国移动支付整体快速增长以及阿里的双11 活动的推动下，阿里的交易系统也在一次一次的交易海啸中快速成长起来。
阿里整个集团不仅完成了去IOE，也完成存储的自研，以及到打磨成为业界顶尖的互联网分布式金融存储产品。
阿里目前分布式存储产品有完全自主研发的金融级分布式关系数据库OceanBase 和阿里数据库产品事业部自研的OLTP 数据库存储引擎X-Engine 等。
OceanBase 作为完全自主研发的金融级分布式关系数据库，支持强一致、高可用、高扩展、高性能、高度兼容和低成本等特性。
OceanBase 是基于单机关系型数据库，根据数据特性分为基线数据和更新数据构建的一种类Bigtable 的分布式存储系统；而X-Engine 定位于为阿里云上的公有云客户提供低成本高性能的数据库服务。
X-Engine 采用了基于LSM Tree 的分布式架构，通过优化和借助硬件加速从而提供更低成本下的高性能的读写的OLTP 存储解决方案。
伴随着微信支付的快速发展，以及用户持续增长和交易量的增长。
腾讯的财付通作为支付底层的服务提供者有自研的金融级分布式数据库TDSQL，不仅支撑微信红包业务，也在腾讯云为更多的企业用户提供分布式数据库解决方案。
由于历史原因，微信支付的核心订单系统没有将所有的可用性转移到分布式存储系统，而是走出了一条基于单机关系型数据库，业务和存储强耦的高可用订单系统方案。
本文的方案是基于微信支付的方案总结和抽象的方案，虽然没有采用一些分布式存储方案，但它同样可以达到高可用，线性扩容的能力。
除了阿里和腾讯，PingCap 是一家专注开源的新型分布式数据库公司，其研发的分布式关系型数据库TiDB 项目具备分布式强一致性事务、在线弹性水平扩展、故障自恢复的高可用、跨数据中心多活等核心特性，并提供HTAP 的一站式解决方案。
虽然TiDB 没有海量的交易，但作为一家专注存储自研的公司，代表了中国自研存储的努力和崛起。
三、系统架构通过上节的描述，订单交易系统的可用性更加聚焦在有状态存储服务的可用性，一些高可用、强一致的分布式存储方案可以解决问题。
也正如前面提到，本文提出的系统没有采用高可用、强一致分布式存储系统，而是采用了基于单机存储，存储和业务强耦的一种订单可用方案。
这里的方案也可以为一些想构建高可用、线性的订单存储，而没有分布式存储系统开发能力的企业提供一些借鉴。
图1: 订单系统架构概览如图1 所示的整个系统的简要结构，整个系统是由代理层和若干的交易单元共同组成的，每个交易单元内包含无状态的逻辑服务和有状态的存储。
整个系统在垂直方向分为三层：代理层、逻辑服务层和存储层。
其中，代理层主要功能包含订单路由和订单重试、逻辑服务层聚合业务特性、数据的增删改查和单机事务等、存储层负责数据的存储；在水平方向是由多个可动态扩缩的交易单元组成。
3.1、交易单元交易单元是系统构成的基本单元，可以通过交易单元的逻辑聚合实现读写分离、冷热分离、差异化服务、和提升版本发布质量等。
整个系统的容量是通过动态的添加和删除交易单元来达到容量的动态扩缩容；系统的可用性通过对存储不可用问题提出针对性的解决方案和优化来提升整个系统的可用性。
系统中各交易单元是物理隔离的，如果存在交易单元不可用，在代理层可以通过跳过不可用交易单元保证订单的创建和订单支付有很高的可用性。
交易单元不可用还是会影响该交易单元内的订单查询和订单退款，实际中订单查询和订单退款相比订单创建和订单支付可以更加柔性和更好的容忍度。
通过上面的描述整个系统通过无状态的代理层和订单重试共同保证系统的创建订单和支付订单有很高的可用性。
交易单元内的无状态逻辑服务采用多机部署，这样一个交易单元内所有逻辑服务同时不可用的概率将会降低，通过选择合适的副本数可以提高整个条带的可用性；交易单元内的存储也是多机部署，一主多备可以保证集群的数据的灾备和可用性，集群内的主备之间采用半同步保证数据的最终一致（或者采用基于Paxos 改造BinLog 的强一致数据存储，例如PhxSQL 等）。