Mobabel

Just One Pure ITer

Category: Java Architecture

[转]分层架构设计 – 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层，简化数据获取过程，提高数据获取效率，向上游屏蔽底层的复杂性 当业务越来越复杂，垂直拆分的系统越来越多，数据库实施了水平切分，数据层实施了缓存加速之后，底层数据获取复杂性成为通用痛点的时候，就应该抽象出数据服务层，简化数据获取过程，提高数据获取效率，向上游屏蔽底层的复杂性

[转]系列 – 从单体式应用到微服务的低风险演变 0

MS Design Princinple

[转]系列 – 从单体式应用到微服务的低风险演变

http://blog.christianposta.com/microservices/low-risk-monolith-to-microservice-evolution/ http://blog.christianposta.com/microservices/low-risk-monolith-to-microservice-evolution-part-ii/ http://blog.christianposta.com/microservices/low-risk-monolith-to-microservice-evolution-part-iii/     讲讲拆分：从单体式应用到微服务的低风险演变 从单体式应用到微服务的低风险演变 II

0

Database Partitioning&Scaling

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

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

0

Performance Diagnosing

[转]如何诊断Java代码中常见的数据库性能热点问题？

1. 写在前面 当我在帮助一些开发者或架构师分析及优化 Java 应用程序的性能时，关键往往不在于对个别方法进行微调，以节省一或两微秒的执行时间。虽然对某些软件来说，微秒级的优化确实非常重要，但我认为这并非着眼点所在。我在 2015 年间对数百个应用进行了分析，发现多数性能与可伸缩性问题都来源于糟糕的架构决策、框架的错误配置、错误的数据库访问模式、过量的日志记录，以及由于内存过度消耗而导致的垃圾回收所带来的影响。

0

System Monitor

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

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