一、《微服务：从设计到部署》--简介

走向单体地狱：

有一个成功的关键业务应用，它已经发展成为一个只有少数开发人员能够理解的巨大单体。它使用了过时、非生产性技术编写，使得招聘优秀开发人员变得非常困难。应用变得难以扩展，不可靠。因此敏捷开发和应用交付是不可能的

微服务-解决复杂问题：

1、服务也可以使用异步、基于消息的通信；

2、通信是由一个称为 API 网关（API Gateway）的中介负责。API 网关负责负载均衡、缓存、访问控制、API 度量和监控（Nginx…）;

3、每个服务都拥有各自的数据库

优缺点：

优点：

a. 把可能会变得庞大的单体应用分解成一套服务，如远程过程调用（RPC）驱动或消息驱动 API

b. 使得每个服务都可以由一个团队独立专注开发，由于服务较小，使用当前技术重写旧服务将变得更加可行

c. 微服务架构模式可以实现每个微服务独立部署，微服务架构模式使得持续部署成为可能。

缺点：

a. 一个缺点就是名称本身。微服务这个术语的重点过多偏向于服务的规模，小型服务只是一种手段，而不是主要目标。微服务的目标在于充分分解应用以方便应用敏捷开发和部署。

b. 开发者需要选择和实现基于消息或者 RPC 的进程间通信机制，由于目标请求可能很慢或者不可用，他们必须要编写代码来处理局部故障，模块间通过语言级方法/过程调用相互调用，这比单体应用要复杂得多

c. 分区数据库架构，在基于微服务的应用中，你需要更新不同服务所用的数据库。通常不会选择分布式事务，不仅仅是因为 CAP 定理。他们根本不支持如今高度可扩展的 NoSQL 数据库和消息代理。你最后不得不使用基于最终一致性的方法，这对于开发人员来说更具挑战性

CAP: Consistency(一致性)：所有的节点得到的数据应该是一样 Availability(可用性):所有节点保持高可用性 Partition to lernece(分区容忍性):指的是网络意义上的分区，节点之间不能通信的时候，系统可以正常提供服务、在保证CP的情况下，虽然没办法保证高可用性，但这不意味着可用性为0，我们可以通过合理的设计尽量的提高可用性，让可用性尽可能的接近100%。同理，在AP的情况下，也可以尽量的保证数据的一致性，或者实现弱一致性，即最终一致性。

d. 测试微服务应用也很复杂

e. ……

微服务实战：

10000 个网站中有超过 50% 使用 NGINX，这主要是因为它有作为反向代理服务器的能力。你可以把 NGINX 放在当前应用甚至是数据库服务器之前以获取各种功能 —— 更高的性能、更高的安全性、可扩展性、灵活性等。

参考：DocsHome/microservices: Microservices from Design to Deployment 中文版《微服务：从设计到部署》 (github.com)