原文地址： 阿里巴巴前架构师 360 度无死角剖析微服务
1. 一些词汇和技术
1）微服务 敏捷开发模式 SOA 分布式服务
2）Spring MVC Zookeeper Dubbo Spring Cloud
3) 服务注册中心 服务网关 OpenStack 云计算 RESTful
4) RPC 领域驱动的分析与设计方法(DDD) ESB
5）Spring Cloud Netflix Spring Boot 微信小程序
6）最终一致性 CQRS Event Sourcing
7）事务补偿机制 熔断机制 QPS 日志聚合
8）AOP + 消息队列 + strom
9）flume + Mq + strom
10）数据库中间件
11）Kubernetes Mesos Docker Swarm
12）ID 生成策略 OSGi Spring RestTemplate
13）Retrofit
2. 只言片语
1）【是否微服务】我以前做过微服务，基本框架是 Spring MVC，微服务之间和微服务与平台之间的访问是通过在 Zookeeper 上的 Dubbo 通讯的，请问这算是微服务吗？
2）【架构范围】微服务架构的范围比较大，Dubbo 和 Spring Cloud 都只是解决了微服务的一部分问题，并未完全覆盖
3）【Doctor】微服务一般都要用到 Docker
3. 核心思想(黄勇)
1）【微服务核心】我认为微服务的核心是：服务注册中心（Service Registry）与服务网关（Service Gateway），它们配合完成服务注册与服务发现。
2）【服务编排】将服务组合起来也成为“服务编排”，有多重做法，可以在服务网关中进行编排，也可以通过中间服务进行编排，我更倾向于后者，这样确保服务网关不包含任何业务，更加轻量级。
3) 【应用场景】我认为在以下几种情况下，可考虑使用微服务架构：
- 应用变得越来越大时
- 项目存在多种开发语言时
- 感觉到经典架构模式太重时
- 修改了一个 bug 需要平滑升级时
- 想对系统进行细粒度监控时
4）【微服务 SOA】
-- 【解决方案】微服务是传统 SOA 的轻量级解决方案，它让 SOA 更加容易落地
-- 【区别】SOA 与 MSA（微服务架构）区别在于系统一体化与服务组件分散化（“微化”）的区别
5) 【微服务技术选型】建议尽可能地轻量级，做到“进可攻退可守”，至于 Spring Cloud 还是其他框架，完全取决于我们对技术本身的理解以及对业务的把控能力，技术也业务需要相互结合才能产生价值
6）【微服务中的事务】
--【消息队列】 可使用消息队列的方式，实现服务之间的事务控制。服务调用完毕，写入消息队列，通过消息驱动的方式调用其他服务。
-- 【服务与服务间事务】在微服务架构中，建议尽量避免服务之间的调用，因此服务粒度的切分是至关重要的；服务间的调用会产生分布式事务问题，建议采用“最终一致性”方法来确保分布式事务，业界有两种常用做法：CQRS 和 Event Sourcing。
--【事务补偿机制】事务补偿机制说简单点就是，在应用程序中通过代码的方式做到数据的还原。一般情况下，我们需借助消息队列与日志追踪等方式来实现
7）【实际问题】
-- 【分布式事务控制】消息队列可用于分布式事务控制，这项技术已经在业界被证实是可用的。此外，还有 CQRS 与 Event Sourcing 技术也可以尝试一下。
-- 【日志聚合】日志聚合可使用业界流行的 ELK，即 Elasticsearch + Logstash + Kibana 来实现，L 用于收集日志，E 用于存储日志，K 用于展现日志。
-- 【方法调用次数统计】方法调用次数统计，不建议放在服务内部通过 AOP 来控制，建议在微服务架构的服务网关（Service Gateway）加以控制。
-- 【服务治理】服务治理可通过 Kubernetes、Mesos、Docker Swarm 等技术来实现，
-- 【服务版本】服务版本可通过 ZooKeeper、Etcd、Consul 等技术来控制，
-- 【服务权限】服务权限可自行实现权限中间件来解决，服务颗粒度划分考验我们的是对业务的深度理解（这才是最为关键的）
-- 【ID生成策略】好的 ID 生成策略需要结合您所面临的实际需求，一般应用场景下，可通过 Redis 来生成并管理 ID，它具备较高的并发能力，且能确保分布式一致性
-- 【开源方案】业界也有其他优秀的微服务开源方案，例如 Java 领域的 Netflix 与 Spring Cloud。当然，我更希望本书所提到的开源方案，可以被更多人接受并应用
-- 【接口】微服务对外的接口不一定局限于 HTTP 或 HTTPS，也可以是 TCP，需要根据具体情况而定。