Chris Richardson 微服务系列
Chris Richardson 微服务系列全 7 篇：
1. 微服务架构的优势与不足
http://blog.daocloud.io/microservices-1/
概述：
优势：
首先，通过分解巨大单体应用为多个服务方法解决了复杂性问题；
其次，这种架构使得每个服务都可以有专门开发团队来开发；
再次，微服务架构模式使得每个微服务独立部署，开发者不再需要协调其它服务部署对本服务的影响；
最后，微服务架构模式使得每个服务独立扩展。
不足：
第一，微服务只是结果，而不是最终目的，微服务的目的是有效的拆分应用，实现敏捷开发和部署，不要陷入本末倒置；
第二，微服务应用是分布式系统，由此会带来固有的复杂性；
第三，同时更新多个业务主体的事务很普遍，在微服务架构应用中，这需要更新不同服务所使用的不同的数据库，分区的数据库架构是一个挑战；
第四，基于微服务架构的应用的测试；
第五，微服务架构模式应用的改变将会波及多个服务，比如，你在完成一个案例，需要修改服务A、B、C，而 A 依赖 B，B 依赖 C，你需要更新服务 C，然后是 B，最后才是 A；
第六，微服务应用的部署。
2. 使用 API 网关构建微服务
http://blog.daocloud.io/microservices-2/
概述：
使用 API 网关的最大优点是，它封装了应用程序的内部结构。客户端只需要同网关交互，而不必调用特定的服务。API 网关为每一类客户端提供了特定的 API，这减少了客户端与应用程序间的交互次数，还简化了客户端代码。
不足是它增加了一个我们必须开发、部署和维护的高可用组件。并且API 网关变成了开发瓶颈。为了暴露每个微服务的端点，开发人员必须更新 API 网关。
3. 微服务架构中的进程间通信
http://blog.daocloud.io/microservices-3/
概述：
在单体应用中，各模块之间的调用是通过编程语言级别的方法或者函数来实现的。而基于微服务的分布式应用是运行在多台机器上的；一般来说，每个服务实例都是一个进程。因此，如下图所示，服务之间的交互必须通过进程间通信（IPC）来实现。
4. 服务发现的可行方案以及实践案例
http://blog.daocloud.io/microservices-4/
概述：
对于基于云端的、现代化的微服务应用而言，服务实例的网络位置都是动态分配的。由于扩展、失败和升级，服务实例会经常动态改变，因此，客户端代码需要使用更加复杂的服务发现机制。
5. 事件驱动的数据管理
http://blog.daocloud.io/microservices-5/
概述：
微服务架构中的数据访问变得复杂许多。每个微服务拥有的数据专门用于该微服务，仅通过其 API 访问。这种数据封装保证了微服务松散耦合，并且可以独立更新。但如果多个服务访问相同数据，架构更新会耗费时间、也需要所有服务的协调更新。
更糟糕的是，不同的微服务通常使用不同类型的数据库。现代应用存储和处理各种类型的数据，而关系型数据库并非总是好选择。对于一些使用场景，特定的 NoSQL 数据库能提供更方便的数据模型、更好的性能和可扩展性。譬如，服务使用 Elasticsearch 这样的文本搜索引擎来存储和查询文本；同样地，存储社交图谱数据的服务可能需要使用 Neo4j 这样的图谱数据库。因此，基于微服务的应用通常会混合使用 SQL 和 NoSQL 数据库，即多语言留存（polyglot persistence approach）。
分区的、多语言留存的架构对于数据存储有很多好处，包括服务的松耦合、更好的性能和可扩展性。然而，它也确实给分布式数据管理带来了挑战：其中一个挑战是如何实现业务逻辑，保持多种服务的一致性，另一个挑战是如何实现检索多个服务数据的查询。
6. 选择微服务部署策略
http://blog.daocloud.io/microservices-6/
概述：
微服务应用由几十甚至数百个服务组成。服务用不同的语言和框架写成，每个都是一个小应用，包括特定的部署、资源、扩展和监控需求，例如，根据服务需求运行若干数量的服务实例。此外，每个服务实例必须配套提供适当的 CPU、内存 和 I/O 资源。更具挑战性的是，尽管如此复杂，部署服务还必须快速、可靠和性价比高。
微服务部署的模式有多种，包括单虚拟机单服务实例和单容器单服务实例。另一个让人倍感兴趣的微服务部署方法则是 AWS Lambda，无服务器部署方案的代表。
7. 将单体应用改造为微服务
http://blog.daocloud.io/microservices-7/
概述：
采取逐步重构单体应用的策略。逐步构建一个由微服务构成的应用，与单体应用并行运行；随着时间推移，原先由单体应用实现的功能不断收缩，最后或者完全消失，或者转变为微服务。