Mobabel

Just One Pure ITer

Category: Distributed Theory

[转]分层架构设计 – 6 APP架构分层 0

Monolith to Distributed

[转]分层架构设计 – 6 APP架构分层

互联网分层架构的本质，是数据的移动。   互联网分层架构演进的核心原则：让上游更高效的获取与处理数据（复用），让下游能屏蔽数据的获取细节（封装）。 不管数据怎么移动，最终都会汇聚到客户端。服务端的分层架构设计已经讲了很多，客户端的分层架构设计应该怎么玩呢，服务端的分层架构设计是否有能够借鉴的地方呢，今天和大家简单聊一聊。

[转]分层架构设计 – 5 数据库中间件 0

Monolith to Distributed

[转]分层架构设计 – 5 数据库中间件

不少朋友经常会问我以下问题： 58到家有没有使用数据库中间件 使用了什么数据库中间件，是自研，还是第三方 怎么实现的，是基于客户端的中间件，还是基于服务端的中间件 使用中间件后，join/子查询/集函数/事务等问题是怎么解决的 … 你是不是也有类似的疑问？

[转]分层架构设计 – 4 前后端分离 0

Monolith to Distributed

[转]分层架构设计 – 4 前后端分离

通用业务服务化之后，系统的典型后端结构如上： web-server通过RPC接口，从通用业务服务获取数据 biz-service通过RPC接口，从多个基础数据service获取数据 基础数据service通过DAO，从独立db/cache获取数据 db/cache存储数据   随着时间的推移，系统架构并不会一成不变，业务越来越复杂，改版越来越多，此时web-server层虽然使用了MVC架构，但以下诸多痛点是否似曾相识？

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

Monolith to Distributed

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

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

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

CAP, Base

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

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