架构整理

支付系统从架构上来说，分为三层;

1. 支撑层： 用来支持核心系统的基础软件包和基础设施， 包括运维监控系统、日志分析系统等。

2. 核心层： 支付系统的核心模块，内部又分为两个部分： 支付核心模块以及支付服务模块。

3. 产品层： 通过核心层提供的服务组合起来，对最终用户、商户、运营管理人员提供的系统。

 

深入理解业务

架构设计方面，业务和架构是要互相配合的，架构在满足业务需求的同时，也可以反过来给业务提需求甚至要求改变业务逻辑已达到系统的最优，

设计阶段要追求完美，实践阶段要考虑性价比，采=

 

 

 

历史数据的迁移、各外围系统的对接等，

 

 

接口层主要实现与Web页面、移动客户端的接口交互，定义统一的接口规范，平台最核心的三个接口服务分别是内容（Feed）服务、用户关系服务以及通讯服务（单发私信、群发、群聊）。
服务层主要把核心业务模块化、服务化，这里又分为两类服务，一类为原子服务，定义是不依赖任何其他服务的服务模块，比如常用的短链服务、发号器服务都属于这一类，图中使用泳道隔离，表示它们的独立性，另外一类为组合服务，通过各种原子服务和业务逻辑的组合，完成的Composite服务，比如Feed服务、通讯服务除了本身的业务逻辑，还依赖于短链、用户、以及发号器服务。
资源层主要数据模型的存，包含通用的缓存资源Redis和MC，以及持久化数据库存储MySQL、HBase，或者分布式文件系统TFS以及Sina S3服务
依赖关系都是从上往下，上层的服务依赖下层，下层的服务不会依赖上层

 

服务层框架

服务层主要涉及RPC远程调用框架以及消息队列框架，这是微博平台在服务层使用最为广泛的两个框架

在系统的健壮性和服务治理方面，有较为成熟的技术解决方案

 

可扩展性较好，前端机、业务服务、资源层面支持按需快速扩容，

可用性较高，多活，无单点，任何机器、资源、服务甚至IDC的异常

 较为完善的监控、报警系统，服务有风吹草动，运维和开发人员能快速感知、定位及处理。

 

 

最下层是基础服务层，提供数据库、缓存、存储、搜索等数据服务，以及其他一些基础技术服务，这些服务支撑了新浪微博的海量数据和高并发访问，是整个系统的技术基础。

中间层是平台服务和应用服务层，新浪微博的核心服务是微博、关系和用户。这些服务被分割为独立的服务模块，通过依赖调用和共享基础数据构成新浪微博的业务基础。

 API 和业务层，各种客户端和第三方应用调用 API 集成到新浪微博的系统中，共同组成一个生态系统

https://www.jianshu.com/p/c4bfa40d04fd

 

 

自动化工具，包括自动化监控，自动化发布，自动化故障修复等，这些自动化工具还在持续开发中，以改善运维水平提高系统可用性

 

在于通过一个完整的获客发卡体系成符合企业商业模式和运营特点的场景，用最有效的方式达成销售的目的；并在这个过程中，有序管理和运营好企业的各种能力资源，用最小代价达成最大的业务目的。

 

 

子商务成功实施，应该至少具备这些基础能力：多终端支撑能力、统一支付能力、统一订单能力、统一商品管理能力、统一多渠道管理能力、快速营销落地能力、统一信息分析能力、系统功能扩展能力、最大化客户体验能力、系统高可用和安全能力、高性能能力、团队建设和发展。下面就一些重点方向进行说明。

 

内容可扩展性

 真 申请页面的各种卡片话术，影响广告提供动态支持

2 提供各种 动态客支持性

功能可扩展性

针对各种扩展功能需求，系统支持统一的方式扩展新的能力，并提供统一的管理

 

系统可扩展性

支持对大量用户访问能力的平滑支持

支持高可用，高安全，并具有高的系统恢复能力

 

系统难点

构建一套全新的柔性的，适变的体系架构，能够持续演进满足未来业务和运营发展的变化需求，即从应变模式改造为适变模式

 

重构

订单量的不断增长，原有的订单存储架构已经不能满足公司的发展了，特别是在大促高峰期，原订单库已经成为抢购瓶颈，已经严重制约公司的发展。

典型的一主多从架构

 

业务系统缺少长期规划，扩展困难

没有使用同一的框架，效率低下

业务边界不清，责任不明确，耦合严重

系统可靠性第，

对业务建模，

服务化解耦

系统处理

优化数据库访问