Microservices
微服务架构使得大型应用分解成一些小型服务并相互通信。每个服务都是独立的，可部署、升级、扩展以及替换，与整体分开。服务之间的通信通常通过HTTP调用（请求/响应）在网络连接上进行。Web套接字，消息队列和远程过程调用（RPC）也可用于连接独立组件。
每个独立的服务专注于单一任务，分离业务单元，并由 Restful 来沟通管理。
本课程的目标是用微服务来开发应用。很少深究原因，而是专注于如何实现。微服务并不容易，伴随着一系列挑战和难以解决的问题。在开始之前请牢记这一点。
优点
分离
通过明确的分离，开发者可以专注于自己的专业领域，如语言、框架、依赖、工具和构建。
例如，前端 JavaScript 工程师开发面向客户端的视图，无需了解后端 API 的底层代码。可以自由选择语言和框架，只需要通过 AJAX 访问 Restful API 来与后端通讯。换句话说，开发人员可以将服务视为黑盒子，因为服务通过API进行通信。隐藏了实际的实现和复杂性。
也就是说，创建一些组织范围的标准是一个好主意，以帮助确保每个团队可以一起工作和运作 - 例如代码质量和样式检查，代码审查，API设计。
明确地分离意味着错误主要局限于开发者正在处理的服务。因此可以将不太重要的服务分配给初级开发者，如果他使其服务瘫痪了，也不会影响到其他服务。
轻耦合也使得应用易于扩展，因为每个服务可以单独部署。也有助于团队间相互等待来完成工作的依赖性。
较小的代码库
较小的代码库往往更容易理解，因为您不必掌握整个系统。这与实体 API 设计的必要性一起意味着微服务堆栈中的应用程序通常更快开发并且更容易测试，重构和扩展。请记住，在所有服务中保持一致的编码标准非常重要，这样开发人员就可以更轻松地从一种服务转移到另一种服务。
加速反馈循环
通过微服务，开发人员通常拥有应用程序的整个生命周期，从开始到交付。而不是将团队与特定的一组技术（如客户端UI，服务器端等）对齐 - 团队更注重产品，负责将应用程序交付给客户自己。因此，他们可以更清楚地了解应用程序在现实世界中的使用方式。这加快了反馈循环，使修复错误和迭代更容易。
缺点
设计复杂性
决定将一部分应用程序拆分为微服务并非易事。通常更容易将其重构为整体整体内的单独模块而不是将其拆分。
一旦你拆分服务就没有回头路了。
网络复杂性
使用单一应用时，通常一切都在一个进程中进行，因此您不必对其他服务进行非常多的调用。当您将应用程序的各个部分分解为微服务时，您会发现在调用函数之前，您必须先进行网络调用。
这可能会导致问题，尤其是在多个服务需要相互通信的情况下，从而在网络请求方面产生类似乒乓效应。您还必须考虑完全关闭的服务。
基础设施
通过多种服务，复杂性从代码库转移到平台和基础架构。这可能是昂贵的。此外，您必须拥有适当的工具和人力资源来管理它。
数据持久化
大多数应用程序都有某种状态层，如数据库或任务队列。微服务堆栈还需要跟踪部署服务的位置和已部署实例的总数，以便在特定服务的新实例启起来时，可以适当地重新路由流量。这通常被称为服务发现。
由于我们将处理容器，因此我们需要特别注意我们如何处理有状态容器，因为它们不应该崩溃。
隔离特定服务的状态以使其不被共享或重复是非常困难的。你经常需要处理各种事实来源，这些事实必须经常和解。同样，这归结为设计。
集成测试
通常，在使用微服务架构开发应用程序时，在部署到临时或生产服务器之前，无法完全测试所有服务。这需要很长时间才能获得反馈。幸运的是，Docker 通过在本地更轻松地将小型独立服务链接在一起，有助于加快此过程。
日志，监视和调试也更加困难。
有关测试微服务的更多信息，请查看微服务架构中的测试策略指南。