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