刨根问底:微服务架构真正意味着什么?

2014-11-12 09:21:00 [ TT 转载 ]

分布式、组件化应用程序的想法可以追溯到很久以前。众所周知的是，8年前以SOA(面向服务的架构)形式出现并达到顶峰。现在，它又回来了——作为微服务架构。

微服务架构和SOA是不一样的。但高层次的想法源于对庞大应用程序的沮丧。Martin Fowler在一片文章中的解释比这个全面得多。把你的应用程序作为服务套件，而不是一个紧密耦合整体的代码来创建时，更容易修改和维护——特别是需要全天候运行的Internet应用程序。只要重构和重新部署几个服务，并不需要重装并重新释放整体。

当你考虑到应用的整个投资组合时，真正的好处就表现出来了：一旦服务共享，冗余工作便可消除。取而代之的是由不同的团队维持着的一堆单一应用程序，每次复制其他人的成果，你就可以从已被其他人建成和部署的现有服务中做出自己的应用程序。请注意，这跟重用代码是不一样的——你实际上只是一个转用的服务作为你应用程序的一部分，并通过API实现其功能。当该服务进行了改进，使用该服务的每一个应用程序都可以受益。

SOA项目往往是自上而下，由带领多个独立的、重塑相同功能的开发团队的管理者驱动。据我所知，微服务架构似乎更多的是草根开发者的趋势。开发人员也不喜欢重复劳动，特别是当他们在比以往更大的压力下去做更多更好的应用程序时。其中的许多Web和移动应用程序都有不同的表示层，但在幕后却是类似的服务。

你可能已经听说过SOA的失败。但它在某些情况下也成功过，这样说是不完全公平的——比较著名地，亚马逊——作为一个趋势，在2008或者2009也受到重挫。为什么会微服务有会出现更好的表现呢？这里有几个原因：

更简单。 SOA的前身是Web服务，Web服务是由IBM和微软为使用SOAP(简单对象访问协议)和XML所定义的。今天，SOAP已经在很大程度上取代了REST(具象状态传输)协议。此外，SOAP需要使用很冗长并且难以一起工作的XML；REST支持较简单的JSON(JavaScript对象符号)数据交换标准，这是Web开发人员尤其喜欢的。

“微”的不同。在使用旧版SOA的日子里，服务可为任何大小，包括用API翻新的笨拙的旧企业应用程序，许多其他的app也依赖于它。一些大的软件厂商甚至尝试把自己的又大又肥的app当成 SOA下“自己的品牌”中心，这很荒谬。虽然还没有人开发出一个大小限制在微服务“微”的硬性，但基本基本理念是基于每个服务执行一个单一的功能。

云计算基础设施。困扰SOA共享服务的一个大问题。为了实现SOA，企业被告知找到在自己的组织之下有多个应用程序共享的“最佳”服务。但是，当过多的应用程序，同时ping通相同的服务时，就会出现减速和超时限定的结果。现在这个问题有一个解决方法：云计算基础架构的自动缩放功能。

新容器技术。很碰巧，大家最喜欢的开源项目，Docker，很可能变成一个加速微服务架构采用的游戏变革者。分解整体应用程序的服务会带来很多的操作开销。Docker和周围的生态系统，包括Mesos和Kubernates，似乎非常适合部署和管理微服务。

更快，更可靠的网络。一个很大的关于SOA的异议是分布式的服务受网络的支配，这可能产生延迟与风险。物理定律仍然适用，但今天的网络比2000年代更快更可靠。

较少的政治活动。真正否定SOA的是——它需要重大的组织变革。当时的想法是将所有遇到阻力的地方的业务功能进行任务切片。微服务架构，相比之下，加快应用程序的开发的方法已经如雨后春笋般有组织地涌现，用简单的互联网本土技术，而不是臃肿的大供应商解决方案，避免不必要的工作。