Mobabel

Just One Pure ITer

Category: Distributed Architecture

[转]分层架构设计 – 3 通用业务服务化 0

Monolith to Distributed

[转]分层架构设计 – 3 通用业务服务化

《互联网分层架构的本质》简述了两个观点： 互联网分层架构的本质，是数据的移动 互联网分层架构演进的核心原则：是让上游更高效的获取与处理数据，让下游能屏蔽数据的获取细节   《分层架构：什么时候抽象DAO层，什么时候抽象数据服务层》中的观点是： 当手写代码从DB中获取数据，成为通用痛点的时候，就应该抽象出DAO层，简化数据获取过程，提高数据获取效率，向上游屏蔽底层的复杂性 当业务越来越复杂，垂直拆分的系统越来越多，数据库实施了水平切分，数据层实施了缓存加速之后，底层数据获取复杂性成为通用痛点的时候，就应该抽象出数据服务层，简化数据获取过程，提高数据获取效率，向上游屏蔽底层的复杂性

0

Database Partitioning&Scaling

[总结]数据库解耦和拆分

随着业务越来越复杂，数据量越来越大，并发量越来越大，数据库的性能越来越低。好不容易找运维申请了两台机器，让DBA部署了几个实例，想把一些业务库拆分出来，却发现拆不出来，扩不了容，尴尬！ 因为数据库强关联在一起，无法通过增加数据库实例扩容，就是一个耦合的典型案例。

0

System Monitor

[转]苏宁穆加如何实现监与控的结合

  1. 一、背景 在当今互联网时代，企业大都采用分布式系统设计和微服务化，内部关系错综复杂，各产品分散，集成度不高。虽有众多日志监控工具，但没有全链路监控，定位问题及根因分析耗时长。同时由于缺乏决策并自动控制（自愈）机制，基本靠人工来排查处理，面对大规模高并发的场景时，对数据中心的性能、安全、稳定性影响缺乏量化，合理性规划时也很难兼顾性能与稳定性、可用性。 此前苏宁已有穆加服务端性能监控（以下简称 Baymax）、穆加调用链监控（以下简称 HIRO）等产品，但这仅仅是在“监”的层面上去主动发现系统出现的一些问题，而没有对解决这些问题做出“控”的动作。基于此，我们研发了穆加决策分析平台（以下简称 ZEUS），它将打通苏宁内部所有的监控渠道，真正意义上使得监控系统具备“控”的能力，通过与运维系统联动，达到系统问题自愈的效果，实现“监”与“控”完美结合。

0

Kafka Basic Theory

[转]Kafka不只是个消息系统

Confluent 联合创始人兼 CEO Jay Kreps 发表了一篇博文，给出了 Kafka 的真正定位——它不只是个消息系统，它还是个存储系统，而它的终极目标是要让流式处理成为现代企业的主流开发范式。

0

Database Theory & Solution

[转]全球最大的支付结算系统：微信每秒50万拆红包数据库是如何支撑运行的？

1. 一、背景 这图是2016年互联网女皇发布的互联网报告里的截图，左图是讲用户每月支付的频率，可以看到微信支付排在最前面的，大概每月支付超过50次，排在第二的是全美借记卡的支付次数。 微信支付单月支付次数大于全美借记卡+信用卡的次数总和，在这数据背后反应出移动支付时代的全面到来，同时也可以看出我们国内的移动支付，无论是产品、用户量、支付频率上，个人认为都是领先全球的。

0

Database Theory & Solution

[转]怎样选择数据平台的建设方案

公司要做数据分析，首先要考虑数据的准备，也就是数据平台的建设，最近接触了几个客户都处于这一环节，而且其中一个在方案选型过程中，也是充满了纠结，而我也并没有在开始阶段给出合理全面的建议。 所以根据自己的认知整理了这篇文章，一是对自己的整理，二是希望通过分享，给大家一些参考的价值。

[转]CAP理论以及服务注册与发现 0

CAP, Base

[转]CAP理论以及服务注册与发现

[Source] https://cloud.tencent.com/info/7e74c9ea2452227c0ebed5366c55026d.html CAP理论是分布式架构中重要理论 一致性(Consistency) (所有节点在同一时间具有相同的数据) 可用性(Availability) (保证每个请求不管成功或者失败都有响应) 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)