Mobabel

Just One Pure ITer

Category: Micro Service Architecture

[转]考拉：传统企业请注意：不够痛就别微服务，有坑 0

SOA Architect to MS Architect

[转]考拉：传统企业请注意：不够痛就别微服务，有坑

在多家传统行业的企业走访和落地了微服务之后，我发现落地微服务是一个非常复杂的问题，甚至都不完全是技术问题，它牵扯到 IT 架构，应用架构，组织架构多个方面。 当时我想微服务既然是改造应用，做微服务治理，类似注册，发现，熔断，限流，降级等，当然应该从应用开发组切入。 一般一开始聊的会比较开心，从单体架构，到 SOA，再到微服务架构，从 Dubbo 聊到 Spring Cloud，但是必然会涉及到微服务的发布和运维问题，涉及到 DevOps 和容器层。

[转]蚂蚁金服异地多活的微服务体系，从“被动挖光缆”到“主动剪网线” 0

MS Design Princinple

[转]蚂蚁金服异地多活的微服务体系，从“被动挖光缆”到“主动剪网线”

蚂蚁金服（当时还是支付宝）从 2013 年起就运行在单元化架构上，除了具备异地容灾能力外，还能做到异地多活，可随时在多城市、多数据中心调配流量。基于单元流量调配机制，可实现大规模集群的蓝绿发布、灰度仿真环境，为充分验证业务正确性、降低故障提供了基础条件。相应地，微服务体系也必须具备单元内收敛、单元间可控路由等能力，来支撑单元化技术架构的落地。本文根据玄霄 2018 年上海 QCon 演讲内容整理。

[转]每秒上万并发下的Spring Cloud参数优化实战 0

Circuit Breaker&Degrade&RateLimit / Feign

[转]每秒上万并发下的Spring Cloud参数优化实战

1. 一、写在前面 相信不少朋友都在自己公司使用Spring Cloud框架来构建微服务架构，毕竟现在这是非常火的一门技术。 如果只是用户量很少的传统IT系统，使用Spring Cloud可能还暴露不出什么问题。 如果是较多用户量，高峰每秒高达上万并发请求的互联网公司的系统，使用Spring Cloud技术就有一些问题需要注意了。

[转]停用Hystrix，改用Sentinel 0

Circuit Breaker&Degrade&RateLimit / High Concurrency, Circuit Breaker, Rate Limit, Load Balance,etc...

[转]停用Hystrix，改用Sentinel

日前，Netflix开源的限流组件 Hystrix在其Github主页宣布，不再开放新功能，推荐开发者使用其他仍然活跃的开源项目。 Hystrix虽然不再开发新功能 ，但对用户的影响应该不会太大，一是因为开发者可以继续使用Hystrix的最新版本1.5.18，二是因为在Spring Cloud生态下，开发者还有其他限流的开源产品可以选择，例如Resilience4j和Sentinel。

[转]美团点评运营配置平台的设计与实践之道 0

MS Design Princinple

[转]美团点评运营配置平台的设计与实践之道

移动终端的开发变得越来越复杂，随之而来的是对 C 端动态化要求越来越高。动态化需要对 C 端里的基础配置、运营资源进行灵活的管理。如何在版本快速迭代过程中，满足业务场景的高效灵活变更？传统的解决方案无法满足这种复杂场景，美团点评基于自身移动运营的实践，打造了稳定、灵活、高效的运营配置平台。本文根据美团点评高级架构师蒋国宝在 QCon 上海的演讲整理而成。

[转]如何用Zipkin做好分布式追踪？ 0

Distributed Tracing

[转]如何用Zipkin做好分布式追踪？

  现代微服务架构由于业务系统模型日趋复杂，分布式系统中需要一套链路追踪系统来帮助我们理解系统行为，明确服务间调用。最近作者请到了 Zipkin 项目的主要开发维护人员 Adrian Cole 来介绍有关 Zipkin 项目的细节内容，可以让大家了解到如何在分布式追踪系统中用好 Zipkin。Adrian 一直在从事云计算相关开源项目的开发，是开源项目 Apache jclouds 和 OpenFeign 的创始人。最近几年，他专注于分布式跟踪领域，是 OpenZipkin 项目的主要开发维护人员。Adrian 目前在 Pivotal Spring Cloud OSS 团队工作。在加入 Pivotal 之前，他还在 Twitter，Square，Netflix 工作过。

0

Command Query Responsibility Segregation (CQRS)

[转]基于CQRS的架构在答题PK小游戏中的实践案例

1. 1. 前言 领域驱动设计（Domain-Driven Design，下文简称 DDD）在微服务时代成为了风口话题，而在 DDD 领域，我们常常看到命令查询与职责分离（Command and Query Responsibility Segregation，下文简称 CQRS）架构的身影。CQRS 架构由于本身只是一个读写分离的思想，实现方式多种多样。比如数据存储不分离，仅仅只是代码层面读写分离，也是 CQRS 的体现；然后数据存储的读写分离，Command 端负责数据存储，Query 端负责数据查询，Query 端的数据通过 Command 端产生的 Event 来同步，这种也是 CQRS 架构的一种实现。本文介绍的是后者这种实现方式的 CQRS 架构在研发实时答题 PK 系统中的实践，此外，我们还会引入事件溯源（Event Sourcing）模式，本文认为结合事件溯源模式，可以更好发挥 CQRS 架构的价值。