微服务的起源
微服务没有官方标准。当人们试图解释什么是微服务时经常会提到面向服务的体系结构(SOA Service-Oriented Architecture)。
SOA predates microservices, and its core principle is the idea that you organize applications into a discrete unit of functionality that can be accessed remotely and acted upon and updated independently.
中文翻译：SOA早于微服务，其核心原则是将应用程序组织成独立的功能单元，可以远程访问并独立操作和更新。
Wikipedia上述定义中的每个单元都是独立服务，它实现了业务的一个方面，并通过某个接口提供其功能。虽然SOA明确指出服务应该是独立的流程，但它并不强制应该使用哪些协议来使这些流程相互交互，并且对于如何部署和组织应用程序保持相当模糊。
SOA服务可以通过进程间通信(IPC Inter-Process Communication)使用同一台机器上的套接字，共享内存，间接消息队列，甚至远程过程调用（RPC Remote ProcedureCalls）进行通信。
通常微服务是SOA的专业版，如果我们想要给出什么是微服务的完整定义，那么最好的方法是首先看看大多数软件是如何构建的。
集中式架构
比如：酒店预订网站。
除了静态HTML内容，该网站还有预订功能，可以让用户预订世界上任何城市的酒店。用户可以搜索酒店，然后使用信用卡预订。
当用户在酒店网站上执行搜索时，该应用程序将执行以下步骤：
- 它针对酒店的数据库运行了几个SQL查询。
- 向合作伙伴的服务发出HTTP请求，以便在列表中添加更多酒店。
- 使用HTML模板引擎生成HTML结果页面。
一旦用户找到了完美的酒店并点击它进行预订，应用程序就会执行以下步骤：
- 如果需要，客户将在数据库中创建，并且必须进行身份验证。
- 通过与银行网络服务进行交互来执行付款。
- 出于法律原因，该应用将付款详细信息保存在数据库中。
- 使用PDF生成器生成收据。
- 使用电子邮件服务向用户发送回顾电子邮件。
- 使用电子邮件服务将预订电子邮件转发给第三方酒店。
- 添加数据库条目以跟踪预订。
这是简化但非常现实模型，应用程序与包含酒店信息，预订详细信息，账单，用户信息等的数据库进行交互。它还与外部服务交互，用于发送电子邮件，付款以及从合作伙伴处获取更多酒店。
在旧的LAMP（Linux-Apache-MySQL-Perl / PHP / Python）体系结构中，每个传入的请求都会在数据库上生成一连串的SQL查询，并对外部服务进行一些网络调用，然后服务器生成HTML响应使用模板引擎。
下图说明了这种集中式架构：
好处：
整个应用程序都在一个代码库中，当项目编码开始时，它使一切变得更简单。构建良好的测试覆盖率非常简单，您可以在代码库中以干净，结构化的方式组织代码。将所有数据存储到单个数据库中也简化了应用程序的开发。您可以调整数据模型，以及代码如何查询方式。
部署也毫不费力：我们可以标记代码库，打包，然后在某个地方运行它。为了扩展它，我们可以运行预订应用程序的多个实例，并运行一些具有一些复制机制的数据库。
如果您的应用程序较小，此模型运行良好，并且易于单个团队维护。
如果项目通常在增长，将整个应用程序放在一个代码库中会带来一些令人讨厌的问题。例如，如果您需要进行范围较大的彻底更改（例如更改银行服务或数据库层），整个应用程序将进入非常不稳定的状态。这些变化在项目的生命周期中是一个大问题，他们需要进行大量额外测试才能部署新版本。
由于系统的不同部分具有不同的正常运行时间和稳定性要求，因此小的变化也会产生附带损害。由于创建PDF的功能导致服务器崩溃，因此将计费和预留流程置于风险中是一个问题。
不受控制的增长是另一个问题。应用程序必然会获得新功能，并且开发人员离开并加入项目时，代码组织可能会开始变得混乱，测试速度会慢一些。这种增长通常最终会出现难以维护的意大利面条代码库，每次开发人员重构数据模型时都会需要复杂的迁移计划。
大型软件项目通常需要几年时间才能成熟，然后它们慢慢开始变成难以理解的混乱，难以维护。项目的开发人员梦想着用最新的框架从头开始构建应用程序。通过这样做，他们通常会再次遇到同样的问题 - 重复同样的故事。
将应用程序拆分为单独的部分，即使生成的代码仍将在单个进程中运行。开发人员通过使用外部库和框架构建应用程序来实现此目的。这些工具可以是内部工具，也可以来自开源软件（OSS Open Source Software）社区。
如果使用像Flask这样的框架，用Python构建Web应用程序，可以让您专注于业务逻辑，并使得将一些代码外部化为Flask扩展和小型Python包非常有吸引力。将代码拆分为小包通常是控制应用程序增长的好主意。
例如，酒店预订应用程序中的PDF生成器可以是一个单独的Python包，它使用Reportlab和一些模板来完成工作。有可能这个包可以在其他一些应用程序中重用，甚至可能发布到社区的Python包索引（Python Package Index PyPI）。
但是你仍在构建一个单独的应用程序，并且仍然存在一些问题，例如无法以不同方式扩展，或者由错误依赖引入的其他问题。您甚至会遇到新的挑战，因为您现在正在使用依赖。如果你的应用程序的一部分使用了库，但是PDF生成器只能使用该库的特定版本。
微服务实现
微服务会将代码组织到几个单独的组件中，这些组件在不同的进程中运行。
组件列表
- 预订UI：前端服务，它生成Web用户界面，并与所有其他微服务交互。
- PDF报告服务：非常简单的服务，可以为收据或给定模板和某些数据的任何其他文档创建PDF。
- 搜索：可以查询的服务，以获取给定城市名称的酒店列表。该服务有自己的数据库。
- 付款：与第三方银行服务交互并管理开票数据库的服务。它还会发送成功付款的电子邮件。
- 预订：存储预订，并生成PDF。
- 用户：存储用户信息，并通过电子邮件与用户交互。
- 身份验证：基于OAuth 2的服务，返回身份验证令牌，每个微服务都可以在调用其他令牌时进行身份验证。
每个组件使用HTTP协议进行通信，并通过RESTful Web服务提供接口
。
没有集中式数据库，因为每个微服务在内部处理自己的数据结构，而进出的数据使用JSON等语言无关的格式。它可以使用XML或YAML，只要它可以由任何语言生成和使用，并通过HTTP请求和响应传播。
Booking UI服务有点特别，因为它生成用户界面（UI）。根据用于构建UI的前端框架，如果界面使用基于JavaScript的静态客户端工具直接在浏览器中生成界面，则Booking UI输出可以是HTML和JSON的混合，甚至是简单的JSON。
微服务是专注于特定任务，是轻量级的应用程序，它提供了缩小的功能列表，具有明确定义的合同。它是单一责任的组件，可以独立开发和部署。
另外可以考虑将基于UDP的小型服务等作为微服务交换二进制数据。本书中，我们所有的微服务是使用HTTP协议的简单Web应用程序，并且当它不是UI时使用和生成JSON。
微服务的好处
- 更加专注
- 小项目，更简单
- 更多扩展和部署选项
微服务的陷阱
- 不合逻辑的分割
过早分割是万恶之源。
- 更多的网络消息
- 数据存储和分片
在保持微服务独立的同时尽可能避免数据重复是设计基于微服务的应用程序的最大挑战之一。
兼容性问题
测试
