对“用微服务架构开发应用”的注解

标签：

下文是对 Chris Richardson（CloudFoundry 的创建者） 在 SlideShare 分享的“Developing applications with a microservice architecture”（需要科学上网，不会的同学学习吧，为了你们好，此处不发表评论）的注解。

在全球最大的视频网站上也有 Chris Richardson 的演讲的视频，自己找吧。我还没来及看，而且我也是普通码农一个，所以下面的内容难免有一些谬误，但技术胜在交流，所以下发表出来。以后我必定会做更新。

P5 The (sometimes evil) monolith

讲 Monolithic（单一的）应用程序的缺点：

1. 妨碍频繁部署
2. 使你的开发环境负担过重
3. 妨碍开发效率
4. 妨碍技术栈的升级

P14 Decomposing applications into services

P16 The scale cube

影响伸缩性的三点

1. 功能分解
2. 数据分区
3. 横向复制（什么意思？）

P20 Service deployment options 服务部署选项

• 虚机
• Docker 类容器
• JVM
• JAR、OSGi Bundle
  越向上隔离度越高，效率越低，向下则相反

P22 服务划分的策略

• 按名词划分
• 按动词划分
• 单一原则
• Unix 风格：就像是 Unix 系统一样，有无数小命令组成，每个命令只关注自己的一小块功能。但这种风格更适合像 Unix 系统规模一样的大系统

服务划分的太少和太多都不好，所以，这是一门艺术。划分服务的目的是让开发和部署更容易，而不能为了服务而服务。

P30 eliminates long-term commitment to a single technology stack

构建模块化、多语言、多框架的应用
注：主要是说 Microservices 有这样的能力，让你能够选择合适的语言和框架完成工作。同样，不能为了语言而语言，为了框架而框架

P31 Two levels of architecture 架构的两个层次

1. 系统层：以 service 为单元。服务直接的接口和通信机制应该相对稳定
2. 服务层：每个服务内部可以使用不同的框架，合适的工具，快速演化

P33 但是也有一系列的缺点

P40 什么时候采用微服务

• 一开始你不需要，如果一开始就采用微服务，那你开发起来会较慢
• 到后来，你将需要微服务，如果你很晚才使用微服务，那重构起来会很痛苦

P41 客户端与服务的通信设计

举个栗子

P43 如果前端直接和后端通信

会产生各种不正式的 API，同时还有对 Web 不友好的协议，比如 AMQP。解决方法是引入 API Gateway

P46 Netflix API Gateway 的设计

没看懂，详细看这里 http://techblog.netflix.com/2013/01/optimizing-netflix-api.html

P47 API Gateway 设计的挑战

当然是对于大型网站来说，挑战很大

P51 浏览器访问多服务的挑战

不再能通过单一的 URL 访问服务了，如何解决？可以用类似与 HAProxy 的技术

P52 服务之间如何通信

有同步的 HTTP，也有异步 AMQP。有流行的 JSON，也有像 Thrift 的那样的二级制协议（当然更有效率。基于 TCP）

接下来揭晓消息和 HTTP 分别作为通信机制的优缺点

P56 另一个挑战：服务发现

选项1：负载均衡器。负载均衡器负责定位服务，接受服务的注册。亚马逊采用这种方式
选项2：客户端自己搞定：架构中只有一个服务注册中心。服务提供者向注册中心注册，客户端则向注册中心查找可用的服务，直接调用。Netflix 采用这种方式。

这两种方式均有链接做详细解释。

P58 Lots of moving parts

Content router 和 API Gateway 的不同。前者在整个系统（机房）之外，可能会包含如 CDN 的功能。后者是系统的一部分

P59 Decentralized data management 去中心化的数据管理

P60 解构服务便意味着解构数据库便意味着更少的耦合

P61 更多样的存储

P62 那数据之间的关联该怎么办

比如订单服务中的订单（表）和客户服务中的客户（表）存在着多对一的关系，那解构的服务和解构的数据如何处理它们之间的管理关系呢？

P63 更多的问题

• 服务A需要读取服务B拥有的数据，肿么办
• 跨服务的事务肿么办？

P65 对于第一个读数据的问题的解决方法一

通过 API 来实现，我们成这个方法是“拉”数据（呃。。。）。好处是实现简单，毕竟调用一下 API 就好了；保证数据是新鲜的（不会有脏数据的问题）
缺点：降低可用性（依赖于服务），增加相应时间

P66 方法二

复制表：在订单服务中也有一个客户表（Customer‘），这个表是客户服务中的 Customer 表的一个复制，但是只包含订单系统所关心的信用额度的数据。同时，订单服务需要提供一个 API 去使得其 Customer‘ 的数据能和客户服务的数据同步

这种方法采用的 DDD 中的有界上下文的设计思想，详见领域驱动设计 Domain Driven Design

这种方法的好处是更好的可用性（不用依赖其它服务）、更好的延迟；缺点是额外的数据复制和同步的复杂度。

我只能说，信用额度这种和钱有关的一旦不同步就不好了啊。所以低延迟高可用的消息队列很重要，比如 Kafka

P69 如何更新和复制分布式的数据呢

P70 分布式事务（比如 JTA）

不说了，总之互联网很少用

P71 事件驱动

只能保证最终一致（前提是消息队列靠谱）
互联网更多的是采用这种方法，所以经常能听到淘宝说它的消息队列多么多么牛Ｘ。一般来说一般的用 RabbitMQ，吞吐更大的用 Kafka。再满足不了需求的就自己搞。其实淘宝的 MetaQ也是抄的Kafka，只是前者用Java，后者用 Scala。再多说点 RabbitMQ 用的是 Erlang。所以如果想再学一门 Java 以外的服务器端开发语言，Scala、Erlang、Go 里面挑一个

说的简单，其实这事件驱动的架构不好设计

P79 Using event sourcing

那用事件驱动如何解决前面的那个栗子呢？看图

API 和事件驱动这两种方法谈不上谁好谁坏

P80 Custemer aggregate 和 EventSource API

都是 Scala 的代码

P86 后面是一个实战

PS. 开源中国博客的标题怎么限制字数限制的这么狠

对“用微服务架构开发应用”的注解

标签：

原文地址：http://my.oschina.net/lifany/blog/359364