对很多企业而言，处理遗留软件现代化问题都是很大的痛点。但是，微服务可能能够有所助益。Brad Irby深入解释了该领域。

遗留软件现代化一直步履维艰。在周围技术世界不断变化的过程中维护应用本身非常痛苦。开发人员都想使用最新的技术，因此要求开发人员停留在旧的技能，使用旧的技术工作，这也很困难。微服务能够提供无需重写任何东西就可以在旧的技术里使用的新功能，从而给这些遗留系统带来了新的生机。

微服务提供了一种方式来获取并且处理应用本身之外的数据。遗留软件和微服务之间的所有通信都是通过JSON完成的，意味着使用数据的遗留应用和微服务本身共享的只有这一种通信协议。因此，可以使用合适的任意语言来编写微服务。需要使用F#编写的业务逻辑来加强ASP经典网站？使用微服务完成处理，并且返回结果。是否已经拥有了Cobol程序需要使用的，由C#编写并且调试的路由？微服务是解决方案。

因为可以用合适的任意语言编写这些服务，它们自然也能让开发人员满意。很少有开发人员愿意维护遗留应用程序，但是如果能让他们体验最新的编程语言和最新的架构，无需被之前存在的架构束缚，那么就更容易说服他们。

微服务也是“传播爱心”的机会，让大家都参与进来。因为在服务和遗留应用程序之间有很大的组件壁垒，所以编写服务的开发人员不需要像遗留软件现代化处理那样属于同一个团队。编写了合适的需求之后，微服务是非常好的可以外包到海外更便宜开发地的项目。它拥有特定的交付需求，是单独的系统，能够在虚拟空间开发，必须是插入即可使用的，从而也可以按需替换。

微服务最大的ROI是关于遗留软件现代化正在移除重写遗留应用的需求。使用这种新方案不仅仅能够加强遗留代码，而且它还帮助消除了从头重写应用的压力——这通常也是一种昂贵的选择。

即使已经决定重写遗留应用，微服务也提供了一种缓慢并且可预测的方式，而且不会违反任何服务级别协议。已有应用上一小步一小步地改动，使用微服务替换某个功能。这样，大家可以缓慢减少遗留应用的规模，从而减少了重写所需要的时间。

使用微服务有上述这些优势，当然也有需要慎重考虑的方面。比如，该方案可能被过度使用。从定义上讲，微服务是小的，但是它们需要完成支持生产环境的首展流程和测试。虽然达到这些目标所需的工作量很小，但是的确存在，并且不能忽略。如果想要使用太多的微服务来加强已有应用，那么可能就需要在各个问题之间均衡考虑。

另一个问题是性能问题。任何时候跨越服务界线，系统性能都会受到一定的影响。微服务通过调用异步实现有助于让应用程序看上去响应更快一些，但是更难（或者不可能）在遗留技术里这么编码实现。当使用微服务作为加强遗留应用程序已有特性的方案时，必须假定该特性的性能会下降。能接受多大幅度的下降取决于业务需求。如果通过微服务在遗留应用程序里实现新功能，会更加容易一些，因为之前用户对此没有性能上的预期。

当然，所有这些都假定遗留语言拥有某些属性。比如，我们假定语言能够构建Web服务调用。虽然语言越古老，可能越难实现这一点，不过我还不知道有什么语言不能构建Web服务调用的。

异步调用也很必要。Web服务的任何异步调用都是灾难可能发生的地方，因为用户很快就会抱怨系统性能。构造异步调用要求多线程的支持，可能很难找到（我说的就是，COBOL）。在进入微服务世界之前，一定要确保这些基本功能是可用的。