微服务架构的特点和挑战

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

一种构建应用程序的方法，针对DevOps和CI/CD进行了优化

将微服务体系结构与更传统的单一方法区分开来的是它如何将应用程序分解为其核心功能。每个功能都称为一个服务，可以独立构建和部署，这意味着单个服务可以运行（或失败），而不会对其他服务产生负面影响。这有助于您接受DevOps的技术方面，并使持续迭代和交付（CI/CD）更加无缝和可实现。

想想你最后一次访问一家在线零售商。您可能使用了网站的搜索栏来浏览产品。该搜索代表一种服务。也许您还看到了从购物者偏好数据库中提取的相关产品推荐。这也是一种服务。您是否向在线购物车添加了商品？你猜对了，另一项服务。

因此，微服务是应用程序的核心功能，它独立于其他服务运行，但微服务体系结构不仅仅是应用程序核心功能的松散耦合，它还涉及重组开发团队和服务间通信，为不可避免的故障、未来的可伸缩性和，以及新的功能集成。

这是如何实现的？通过调整面向服务体系结构（SOA）的基础来部署微服务。

这听起来很熟悉。。。

如果将应用程序分解为其核心功能并避免单一功能的陷阱听起来很熟悉，那是因为微服务体系结构风格类似于面向服务的体系结构（service-oriented architecture，SOA），这是一种已经成熟的软件设计风格。

在应用程序开发的早期，即使对现有应用程序进行最小的更改，也需要使用自己的质量保证（QA）周期进行批发版本更新，这可能会减慢许多子团队的速度。这种方法通常被称为“单片”，因为整个应用程序的源代码构建在单个部署单元中（如.war或.ear）。如果某个应用程序的部分更新导致了错误，那么整个应用程序都必须离线、缩小并修复。虽然这种方法对于小型应用程序仍然可行，但成长中的企业无法承受停机时间。

进入面向服务的体系结构，它将应用程序构造成离散的、可重用的服务，这些服务通过企业服务总线（EnterpriseServiceBus，ESB）进行通信。在此体系结构中，每个围绕特定业务流程组织的单独服务都遵循通信协议（如SOAP、ActiveMQ或Apache Thrift）通过ESB共享它们自己。综上所述，这套通过ESB集成的服务包括一个应用程序。

一方面，这允许同时构建、测试和调整服务，而无需更多的单一开发周期。另一方面，尽管ESB代表了整个系统的单一故障点，因此在某种程度上，消除整体的努力只创建了一个新的故障点：ESB，它可能会使整个组织陷入瓶颈。

从SOA到微服务

有什么区别？微服务可以相互通信，通常是无状态的，因此以这种方式构建的应用程序可以更容错，更少依赖于单个ESB。这还允许开发团队选择自己的工具，因为微服务可以通过语言无关的应用程序编程接口（API）进行通信。

考虑到SOA的历史，微服务实际上并不是一个全新的想法。然而，由于集装箱技术的进步，微服务变得更加可行。使用Linux容器，您现在可以在同一硬件上独立运行应用程序的多个部分，并对其各个部分和生命周期进行更大的控制。随着API和DeVOPS团队，集装箱化的微服务是云本地应用的基础。

微服务体系结构的好处是什么？

微服务通过分布式开发为您的团队和日常工作提供支持。您还可以同时开发多个微服务。这意味着更多的开发人员同时在同一个应用程序上工作，从而减少了开发时间。

更快地准备上线

由于开发周期缩短，microservices体系结构支持更灵活的部署和更新。

高度可扩展

随着对某些服务需求的增长，您可以跨多个服务器和基础架构进行部署，以满足您的需求。

有弹性的

这些独立的服务在正确构建时不会相互影响。这意味着，与单一应用程序模型不同，如果一个部分失败，整个应用程序不会崩溃。

易于部署

由于基于微服务的应用程序比传统的单一应用程序更模块化、更小，因此这些部署带来的担忧得到了消除。这需要更多的协调，服务网格层可以提供帮助，但回报可能是巨大的。

可到达的

由于较大的应用程序被分解为较小的部分，开发人员可以更容易地理解、更新和增强这些部分，从而加快开发周期，特别是与敏捷开发方法相结合时。

更开放

由于使用了polyglot API，开发人员可以自由地为必要的功能选择最佳的语言和技术。

微服务的挑战是什么？

如果您的组织正在考虑转向微服务体系结构，请期待改变人们的工作方式，而不仅仅是应用程序。组织和文化变革被确定为挑战，部分原因是每个团队都有自己的部署节奏，并负责与自己的客户群一起提供独特的服务。这些可能不是典型的开发人员关注的问题，但它们对于成功的微服务体系结构来说是必不可少的。

除了文化和流程之外，复杂性和效率是基于微服务架构的两大挑战。Red Hat Mobile平台架构师John Frizelle在2017年红帽峰会上的演讲中阐述了以下八个挑战类别：

• 构建：您必须花时间确定服务之间的依赖关系。请注意，由于这些依赖关系，完成一个构建可能会触发多个其他构建。您还需要考虑微服务对数据的影响。
• 测试：集成测试以及端到端测试可能比以往任何时候都更加困难和重要。要知道，体系结构的某个部分出现故障可能会导致几步之外的某个部分出现故障，这取决于您如何构建服务以支持彼此。
• 版本控制：更新到新版本时，请记住可能会破坏向后兼容性。您可以构建条件逻辑来处理这个问题，但这会变得很难处理，而且速度很快。或者，您可以为不同的客户机提供多个实时版本，但这在维护和管理方面可能更复杂。
• 部署：是的，这也是一个挑战，至少在初始设置中是这样。为了使部署更容易，您必须首先投资大量的自动化，因为微服务的复杂性对于人工部署来说已是压倒性的。想想你将如何推出服务，以及以什么顺序推出服务。
• 日志记录：对于分布式系统，您需要集中式日志来将所有内容汇集在一起。否则，规模就无法管理。
• 监控：对系统进行集中查看以查明问题的根源是至关重要的。
• 调试：通过本地集成开发环境（IDE）进行远程调试不是一个选项，它不能跨数十个或数百个服务工作。不幸的是，目前还没有关于如何调试的单一答案。
• 连接性：考虑服务发现，无论是集中的还是集成的。