微服务架构读书摘要

2018-04-22  本文已影响21人  nextliving

最近读了Irakli Nadareishvili和其它人合著的关于微服务架构的新书《 Microservice Architecture》，书中很多观点让人耳目一新，将其中一部分摘录于此，方便日后查阅。

charpter 5

这一章主要谈服务设计(service design),在谈到微服务的API设计的时候主要谈到了2种：message-oriented和Hypermedia-driven。另外比较了系统工程里常见的数据持久化模型：结构化模型(structural modeling)和事件源模型(event sourcing)。

message-oriented

Netflix relies on message formats like Avro, Protobuf, and Thrift over TCP/IP for communicating internally and JSON over HTTP for communicating to external consumers (mobile phones, browsers)

这段说明公司内部信息传送使用类似于avro,protobuf和thrift之类的数据格式，而用户链接到某个公司的服务使用基于Http的JSON数据格式

Hypermedia-driven

Amazon’s API Gateway and App‐ Stream APIs both support responses in the Hypertext Application Language (HAL) format.

一些大公司API支持HAL格式的数据

​

​

To learn more about hypermedia APIs and how to design them, check out the book RESTful Web APIs by Mike Amundsen, Leo‐ nard Richardson, and Sam Ruby.

如果想了解什么是hypermedia api,请参考这本书《RESTful Web APIs by Mike Amundsen, Leo‐ nard Richardson, and Sam Ruby》

Event Sourcing

Event sourcing is all about storing facts and any time you have “state” (structural models)—they are first-level derivative off of your facts. And they are transient.

—Greg Young, Code on the Beach, 2014

这段话是本书作者从Greg Young的一次演讲中摘录的，可以在Youtube上观看这个视频：Greg Young - CQRS and Event Sourcing - Code on the Beach 2014。这段话的意思是，结构化模型（structural model）保存的只是当前时间的状态(state)，而事件源模型保存的是从过去到现在所有事件（state）,前者只是一个状态，后者对应多个状态。举个例子，银行系统使用事件源模型，你要查账户余额，这个余额不是存储在数据库中的一个值(当前余额的状态),而是根据过去所有的事件(event)或者说状态(state)计算出来的，比如说前天你开户并存了100，银行会记录一个事件或者说状态(event==state),昨天你取了10块，银行又记录了一个事件(状态)，今天你取了40块，银行记录了第3个事件(状态)，你的帐户余额根据之前的3个事件计算应该是50块，如果你觉得不对，银行会打印一个单子，上面是从前天开户到今天为止发生的3个事件(状态)。

​

chapter 6

本章讨论系统设计和操作（System Design and Operations）

Independent Deployability

One of the core principles of the microservice architectural style is the principle of independent deployability—i.e., each microservice must be deployable completely independent of any other microservice. Some of the most important benefits of the architectural style rely on faithful adherence to this principle.

实施微服务一个很重要的准则是要能够独立部署，不依赖其它服务。但是怎么才能够独立部署呢？基于轻量的包部署方案，如Java的Jar,War和Ear,ruby的Gems,node的NPM Modules,python的pip package并不是理想方案，它们相互之间会干扰。如果为了防止干扰而在每台物理机上只部署一个微服务，那么开销是很多公司无法承担的。比如一个公司有500个微服务，那么为了系统的健壮性，可能需要每个服务部署3个，总量就是1500。综合考虑下来，微服务的部署单位最好是容器，而容器里最流行的是Docker.

Docker and Microservices

Run only one process per container. In almost all cases, you should only run a single process in a single container. Decoupling applications into multiple containers makes it much easier to scale horizontally and reuse containers. —Docker documentation

可以说docker和微服务相互促进了对方的发展。Docker采用了Unix的设计哲学，即专注做一件事，并把它做好(do one thing, and do it well)。欲了解Docker设计哲学及最佳实践请点击这里那么什么是专注做一件事呢？就是一个Docker容器只运行一个微服务(microservice)。

The Role of Service Discovery

Note that since typically many services are deployed on the same host, we cannot address a microservice by just an IP address. There are usually too many microservi‐ ces, and the instances of those can go up and down at any time. If we allocated an IP per microservice, the IP address allocation + assignment would become too compli‐ cated. Instead, we allocate an IP per host (server) and the microservice is fully addressed with a combination of:

1. IP address (of the host)

2. Port number(s) the service is available at on the host

每一台物理机上部署多个容器(也就是多个微服务),那么怎么定位需要的服务呢?答案是给物理机(host)分配一个IP地址，不同的容器分配不同的端口号(port number)。也就是使用IP+端口号定位服务。但是问题来了：一个容器或者说微服务是否能够始终使用同一个端口号？在实际开发中，不同的微服务可能是由不同的团队开发，如果某个微服务一直占用固定的端口，可能造成不同团队的微服务发生冲突，为了避免冲突需要跨团队的协调(coordination),这会加大企业的开发成本，所以是不可行的。所以，微服务需要使用动态端口，动态调度微服务端口对外提供服务的过程叫做服务发现(service discovery)。服务发现有一些现成的解决方案，低维度(low-level)的有CoreOs的Etcd 和HashiCorp的Consul，对架构师而言它们能提供更多的可控性和可见性，但是会更麻烦一点，因为需要决定哪一个微服务运行在哪一台物理机(host)上。高纬度的服务有Google的Kubernetes和Docker的Swarm，它们提供容器级别的调度(container-scheduling),不需要考虑哪个微服务运行在哪个物理机上，只需要告诉服务发现系统可供一个容器使用的全部物理机资源(host pool’s resources)。还有一个管理容器的技术是Mesosphere,它比Kubernetes和 Swarm更加抽象，用于管理数据中心，但是鉴于Docker公司自己在发展数据中心容器管理技术，Mesosphere前途未卜。

参考

上一篇 下一篇

猜你喜欢

热点阅读