企业使用有效的应用程序方法重构微服务的3个主要步骤使当今的企业组织能够以前所未有的规模创建和管理其模块化系统。虽然重构单体应用程序取得了不同程度的成功，但构建微服务架构对于组织而言可能是一项重大投资，但无法立即获得投资回报。在本文中，我们将向读者朋友介绍如何通过逐步重构您的企业应用程序来实现微服务的成功。同时，我们还将向您介绍如何构建企业微服务的基础以改进面向服务的架构，以及如何受益于易于开发和维护、应用程序组件的独立可扩展性等。微服务架构是一种新的架构形式，用于创建松散耦合但自治的服务。DevOps、平台即服务(PaaS)、容器和持续集成与交付(CI/CD)方法等新兴技术趋势使当今的企业组织能够创建和管理这些模块化系统的面向服务架构(SOA)等服务.虽然重构单体应用程序取得了不同程度的成功，但有效使用微服务的关键在于组织应该如何以及为什么要使用微服务来构建应用程序。改进面向服务的体系结构面向服务的体系结构(SOA)通常定义为通过网络向其他组件提供服务的应用程序组件。SOA的目标是创建弹性的分布式应用程序，而不需要复杂的集中式组件。但是，SOA与组织结构密切相关，用于支持新的内部结构。因此，它的成功在很大程度上取决于由此产生的重构组织能力和设计架构的团队结构。SOA不是创建松散耦合但自治的系统，而是创建需要复杂基础架构的高度脆弱的系统。此外，早期的SOA实施造成了供应商锁定，因为专有中间件通常专注于逻辑的、持久的集成管理域。微服务架构最初是从在构建应用程序的每个步骤（从开发到部署再到操作）中对SOA的承诺开始的。微服务架构侧重于简化技术，以使用简化的组件构建复杂的系统。基于重量级非标准化平台的集中式逻辑和集成基础架构被基于异步HTTP或消息传递协议的简单标准化通道所取代。SOAP、XML等重量级协议和数据格式被基于HTTP的REST的轻量级JSON语言所取代。每个微服务都有自己的数据存储，无需集中管理和持久化。微服务使用持续集成(CI)和持续交付(CD)方法和实践，以及SOA中不常见的几个关键组件，例如多语言编程和持久性。容器或不可变虚拟机(VM)。弹性、可编程的基础设施即服务(IaaS)和PaaS。灵活、IT响应的创新解决方案1.更快的部署微服务的范围更小，依赖于对域边界的关注和一致的域建模，并且需要更少的代码。包括专用集中式独立存档（通常打包在Linux容器和CI/CD中）在内的部署策略可实现更快、更可靠的部署。因此，软件开发生命周期通常会变得更快。新功能和错误修复以及经过全面测试的安全补丁将更快发布。2.模块化控制借助微服务，每个服务都可以独立扩展，以满足临时或季节性的流量增长，完成批处理，满足其他业务需求。改进的故障隔离将服务问题（例如内存泄漏或打开的数据库连接）限制为仅限于该特定服务。微服务的可扩展性与云服务的灵活性相辅相成，让您的企业在处理更多客户服务需求的同时，在不中断服务的情况下改进服务。开源技术解决方案和组织方法的更多选择正在推动微服务市场。通过这种方式，微服务可以减少供应商锁定并消除长期技术承诺，让企业客户可以选择满足企业特定IT和业务目标所需的工具。为微服务打下坚实的基础要通过微服务取得成功，组织必须首先为其整体架构打下坚实的基础。还必须考虑和建立模块化、领域边界和基本的分布式系统理论，以实现微服务的全部优势。此外，微服务为更复杂的系统创造了巨大的好处。虽然每项服务都是完全独立的，但必须满足运营要求，这包括以下功能：DevOps。平台即服务。容器或不可变的虚拟机。服务复制、注册和发现。主动监控和警报。鉴于满足这些要求可能是一项重大投资，而且不会立即获得投资回报，因此使用微服务对每个团队或项目来说都不是划算的。评估单体方法可确保应用程序是根据现实的设计原则构建的，并且域边界得到正确定义，同时如果需要可扩展性，则逐渐过渡到微服务架构。例如，即使是一个基本的购物车应用程序也应该包括以下几个方面：关注点分离。使用定义良好的应用程序编程接口(API)来实现高内聚和低耦合。遵循“得墨忒耳法则”，也称为最少知识原则，实现独立的接口、API和部署。用于对相关对象进行分组的领域驱动设计。一旦根据软件架构原则构建的单体应用程序需要调整大小，就可以将其重构为微服务。最有效的重构方法包括以下步骤：1.确定应用程序域内的业务边界和语义差异，并开始将每个域分解为自己的微服务。2.找到经历最多变更请求的组件，例如与价格计算或监管变更相关的业务规则更新；或经常修补以解决安全问题的漏洞。3.在定义了基本的基于域的微服务之后，改进用于允许服务交互的API。使用聚合器、代理、链接、分支、事件驱动和其他设计模式编写这些API。精通技术的团队组织在微服务方面的成功取决于其组织结构，而不是其技术。因此，具有相应组织结构、跨职能和自治的灵活团队是关键。建立高效、技能娴熟的团队需要围绕功能而不是结构重新调整企业员工队伍。例如，亚马逊有一个非常著名的“两个披萨团队”的组织理论，意思是8到10人的团队人数恰好相当于能吃到2个披萨的人数。这种规模的团队负责创建和维护他们的服务。根据康威定律（Conway'sLaw），商业组织只能产生模仿组织结构的设计。例如，分组团队，包括开发、运营、质量保证和安全，对灵活性和延迟施加了限制。在过渡到微服务之前建立一套DevOps实践可以减轻或防止这些问题，并通过预先确定通信策略而不仅仅是有效的微服务架构来避免创建失败的SOA。有效的管理工具除了精心设计的软件和高效、有组织的团队，实现高度可扩展的架构还需要工具来帮助您的企业管理其他服务和应用程序组件，包括：服务注册和发现工具，例如Kubernetes。容器容器化应用（如Docker）的标准化打包和复制大规模容器（如Kubernetes）的编排工具。RedHat的OpenShift包括这两种经过验证的开源技术。CI环境创建工具，例如Jenkins或适用于Docker和Kubernetes的Shippable。Nexus等依赖解析工具。故障转移和弹性工具，包括Hystrix和Ribbon等库。服务监控、警报和事件通知工具，例如ELK（ElasticSearch、LogStash和Kibana）堆栈。数据管理转向微服务的公司的另一个重要考虑因素是数据管理。与SOA不同，微服务不共享数据。相反，每个微服务都有一个单独的物理数据存储和多存储持久性，允许各种数据库引擎在每个微服务下运行。因此，可以根据每个服务选择数据存储，而不是将所有数据存储在一个企业关系数据库管理系统(RDBMS)中。但是，维护企业数据库的多个副本可能会增加许可的成本和复杂性。此外，数据存储可能需要保持一致。通用提取、转换和加载(ETL)或数据虚拟化工具可以帮助实现数据规范化，而事件摄取是一种众所周知的设计模式，可以帮助实现一致的数据存储以实现更改的可追溯性。结论微服务架构可以为企业组织提供许多优势，从不同应用程序组件的独立可扩展性到更快、更轻松的软件开发和维护。然而，微服务并不总是对每个团队或项目都有好处，并且可能会导致大量投资而没有立即获得投资回报。向微服务的过渡应该是一个循序渐进的过程，遵循从仅重构现有应用程序的一部分到部分过渡的方法也可以使组织受益。要通过微服务取得成功，企业组织必须首先基于现有平台标准构建设计良好的应用程序，然后根据需要将应用程序重构为微服务集，以满足企业的业务需求。有了合适的人员、流程和工具，微服务可以提供更快的开发和部署、更容易的维护、改进的可扩展性，并免于长期的技术锁定承诺。
