什么是微服务？

微服务是一种用于构建应用的架构方案。微服务是松散耦合的分布式架构框架，因此一个团队的更改不会破坏整个应用。使用微服务的好处是，开发团队能够快速构建应用的新组件，以满足不断变化的业务需求

微服务是为 DevOps 和 CI/CD 优化的构建应用方法，有别于更为传统的单体式方案，可将应用拆分成多个核心功能。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。这有助于您更好实现 DevOps 的技术，并让持续集成和持续交付（CI/CD）更加顺畅、容易实现。

请回想一下您上次在线购物时的情景。您应该使用了网站上的搜索栏来浏览产品。这个搜索功能就是一项服务。您可能也看到了相关产品推荐，这些推荐项均来自顾客偏好数据库。而这也是一项服务。您有将商品添加到在线购物车中吗？没错，这又是另一项服务。

所以说，微服务就是应用的各项核心功能，而且这些服务均可独立运行。但是，微服务架构不只是应用核心功能间的这种松散耦合，它还涉及重组开发团队、涉及如何进行服务间通信以应对不可避免的故障、满足未来的可扩展性并实现新的功能集成。

那么这该如何实现呢？只需对面向服务的架构（SOA）的基础稍加调整，即可部署微服务。

觉得“将应用拆分为多个核心功能，以免受困于单体式结构陷阱”这种做法很耳熟？这是因为微服务架构模式与面向服务的架构（SOA）类似，而 SOA 已经是一种非常成熟的软件设计模式。

早期在开发应用时，即使要对现有应用做很小的改动，也需要对整个版本及其质量保证（QA）周期进行批量式更新，而这很可能会影响很许多子团队的工作推进速度。这种方案常被称为“单体式”，因为整个应用的源代码都被构建到了单个部署单元（如 .war 或 .ear）中。如果应用因某个部分的更新而出错，则整个应用都要下线，然后缩减，再加以修复。虽然这种方案如今仍适用于小型应用，但是众多正在成长中的企业无法承受停机所带来的影响。

改用面向服务的架构后，应用被构建为可重复使用的离散型服务，这些服务会通过企业服务总线（ESB）进行通信。采用这种架构时，各项服务会分别围绕特定的业务流程来规划，并会遵循相应的通信协议（如 SOAP、ActiveMQ 或 Apache Thrift）通过 ESB 进行共享。在通过 ESB 集成后，这套服务就可以形成一个完整的应用。

一方面，这种架构方式使得各项服务可以同时构建、测试和调整，不会再受限于单体式开发周期。另一方面，虽然使用 ESB 意味着整个系统只会出现单点故障，但在某种程度上，消除单体式结构只会形成新的故障点：即 ESB 本身，因此它可能会成为整个企业的瓶颈所在。

有何区别？微服务可以相互通信，而且这种通信通常都是无状态的，所以采用这种方式构建的应用容错性更高，对于单个 ESB 的依赖性也更低。由于微服务可以通过与语言无关的应用编程接口（API）进行通信，开发团队也可以自行选用所需工具。

纵观 SOA 的整个历史，我们不能说微服务是一个全新的概念。但是，得益于容器化技术的不断改进，微服务的可行性也越来越高。现在，您可以借助 Linux 容器在同一硬件上单独运行一个应用的多个部分，还能更好地控制每个部分及其生命周期。与 API 和 DevOps 团队一样，容器化微服务也是云原生应用的重要基础。

微服务可通过分布式部署，大幅提升您的团队和日常工作效率。您还可以并行开发多个微服务。这意味着更多开发人员可以同时开发同一个应用，进而缩短开发所需的时间。

如果您的企业正在考虑迁移到微服务架构，那么不仅是应用要变，相关人员的工作方式也会随之而变。在某种意义上，改变企业和文化并不容易，因为每个团队都有自己的部署节奏和所负责的服务，而且这些服务都拥有自己的客户群。这些可能并不是开发人员通常要担心的问题，但是这些问题却决定了微服务架构能否取得成功。

除了文化和流程之外，复杂性和效率问题是基于微服务的架构所面临的另外两大挑战。红帽移动部平台架构师 John Frizelle 在他 2017 年红帽峰会演讲中提到了以下八类挑战：

1. 构建：您必须花时间明确各个服务间的依赖关系。要知道，由于存在这些依赖关系，当您完成一个构建时，可能会触发多个其他构建。您还需要考虑微服务对于数据的影响。
2. 测试：集成测试和端到端测试可能会前所未有的难以实施，但却更加重要。根据您在架构相互支撑的服务时所采用的不同方式，架构中的一个部分出现故障，很可能会导致其他部分也随之出现故障。
3. 版本管理：在更新到新版本时，请记住：向后兼容性可能会因更新操作而失效。要解决这一问题，您可以利用条件逻辑来进行构建，但是构建会变得繁复、难以控制且快速。或者，您也可以为不同的客户端维护多个活跃版本，但是相关的维护和管理工作会变得更加庞杂。
4. 部署：没错，这也是一大挑战，至少是首次设置时所要面临的一大挑战。为了简化部署，您必须先大量投资自动化，因为人工部署无法应对微服务的复杂性。请好好思考您要以何种方式以及怎样的顺序来部署各项服务。
5. 日志记录：使用分布式系统时，您需要利用集中式日志将所有相关信息集中到一处。否则，积累的日志数量将让您难以招架。
6. 监控：您必须通过一个集中式视图来了解整个系统的情况，以便找出问题的根源。
7. 调试：无法通过本地集成开发环境（IDE）进行远程调试，因为这种方式无法涵盖数十个或数百个服务。不幸的是，关于应该如何进行调试，目前还没有标准答案。
8. 连接：请考虑使用服务探索功能，无论是集中式的还是集成式。