不同类型的微服务？

摘要：

目前对微服务的讨论大多都是关于如何从头开始进行构建的，但是Mark Little认为，微服务的初衷在于改造已有的应用，提高其敏捷性，他讨论了在这种场景下，实现微服务的最佳实践。

最近，有许多微服务领域的讨论，但是这些讨论大多都是关于如何从头开始构建微服务应用的，Mark Little认为，微服务的初衷在于改造已有的应用，提高其敏捷性，他讨论了在这种场景下，实现微服务的最佳实践。

Mark Little博士是Red Hat中间件部门的工程副总裁，他领导着JBoss的技术方向和研究/开发工作。在此之前，他曾经担任过SOA技术开发的主管，并负责标准的制订。

在Mark Little最新的一篇博客文章中，他回顾了自己从事微服务相关的一些经历和对微服务的认识，他依然愿意在这个领域不断思考，并与其团队成员进行交流，从而推动行业思想的发展。

在这个过程中，有些困扰他的问题变得逐渐清晰。长期以来，人们思考的可能是微服务与SOA、分布式系统以及DevOps的关系，而且也有很多的项目和产品来帮助开发基于（微）服务的架构。但是，除Red Hat以外，大多数关于微服务的文章都是从头开始构建的。这其实也反映了大多数开发工作的关注点：从头（Greenfield）开发，重新对系统进行架构，然后完全重建。

不过，微服务最初并不是这样的，如果读一下最初的文献的话，尤其是来自Netflix的文章，就会发现微服务的理念（或者Adrian Cockcroft最初所说的“Adrian Cockcroft”）是与已有系统息息相关的，它致力于将它们重构为组件（服务），这些组件能够独立地部署、版本化和发布。这里的理念在于为已有的系统（brownfield）构建微服务。Mark Little虽然一开始就知道这些背景，但是一直以来他始终认为这种方式与从头开始构建所使用的过程、工具以及方式都是完全相同的。直到最近，他才意识到中间的差别。

有些团队会基于已有的系统进行改造，实现微服务，这是很有价值的。大多数人所面临的都是已有的应用，就像Netflix那样，因此这种方式更具有实用性。它不需要我们好高骛远，每次只需进步一点点即可，这方面是作者以前所没有太多关注的。为了支持这些微服务，也需要对基础设施进行一些很重要的简化。

在一个样例中，他们所面临的是单体应用中的已有组件。因为团队是基于Java EE的，所以具体的表现形式就是多个WAR（Web Archive）或JAR（Java Archive），这些文件会放到一个EAR（Enterprise Archive）中，但是这个例子本身与编程语言和框架是无关的。在这个例子中，目标是将单个组件拆分为微服务，这样当某个WAR中的内容发生变化的时候就不需重新创建整个EAR包了。

如果从完全重建的角度来看，这其实没有实质性的不同。不过，在分布式场景方面，我们可以采取一些变化，至少可以进行简化，这里不需要命名服务（或类似的机制）来定位各种各样的服务所在的位置，同时也不需要SLA。实际上，因为我们知道服务的API，并且这里的目标在于提升开发过程的敏捷性，所以，可以将API硬编码到“客户端”中（应用的其他部分）。从事后来看，很多地方都是可以硬编码的。可以借助地址绑定或底层的网络，如REST/HTTP使用URL来表示服务的名称/地址，当然，这样的话需要DNS实现绑定。

到目前为止，这是可行的，到一定程度之后，就会引入传统分布式系统的复杂性了，不过，我们还没到那一步。团队的关注点在于：“作为开发人员，我该从哪里开始拥抱微服务呢，在不开发、不安装过多基础设施的前提下，该如何取得成功呢？”。Mark Little认为这种方式的简化/硬编码/依赖基础设施能够在一定程度上提供帮助。

当提到微服务时，我们经常读到的内容就是中心化的日志、事件驱动方式、协作（orchestration）以及部署技术，但是，当面临预先定义的组件/服务时，如果我们想借助微服务来提升敏捷性的话，这些技术其实并没有那么重要。借助硬编码以及一些自动化的方式，完全就能实现。

这是一种新型的微服务吗？事实上并非如此，这是一种不断演化的方式，其实与之前的CORBA和Java EE应用并无分别，我们会通过硬编码、接口的方式进行手动编码，随着分布式应用复杂性的不断增长，开发人员需要基础设施和工具的更多帮助。所以，这种方式毫无疑问也是微服务，因为它的目标依然是让团队更加灵活、具有独立的生命周期，只不过它更加聚焦于某一点，或者说更加实用。

在将已有的系统往微服务架构改造的过程中，Mark Little所述的这些观点，应该会对我们提供一些借鉴和帮助。