云计算 频道

微服务架构 原来应用开发还可以这么美好

  单体应用这种传统开发思维已经难以在新时代站住脚了。

  一个简单的应用会随着时间推移逐渐变大。在每次的sprint中,开发团队都会面对新“故事”,然后开发许多新代码。几年后,这个小而简单的应用会变成了一个巨大的怪物。

微服务架构原来应用开发还可以这么美好

  一旦你的应用变成一个又大又复杂的怪物,那开发团队肯定很痛苦。敏捷开发和部署举步维艰,其中最主要问题就是这个应用太复杂,以至于任何单个开发者都不可能搞懂它。因此,修正bug和正确的添加新功能变的非常困难,并且很耗时。另外,团队士气也会走下坡路。

  最后,单体式应用使得采用新架构和语言非常困难。比如,设想你有两百万行采用XYZ框架写的代码。如果想改成ABC框架,无论是时间还是成本都是非常昂贵的,即使ABC框架更好。因此,这是一个无法逾越的鸿沟。你不得不在最初选择面前低头。

  相对于单体(Monolithic)应用而言,微服务是采用一组服务的方式来构建一个应用,服务独立部署在不同的进程中,不同服务通过一些轻量级交互机制来通信,例如 RPC、HTTP 等,服务可独立扩展伸缩,每个服务定义了明确的边界,不同的服务甚至可以采用不同的编程语言来实现,由独立的团队来维护。

微服务架构原来应用开发还可以这么美好

  比喻来讲,单点服务是把所有的东西放在一个大盒子里,这个大盒子里什么都有。微服务更像是车箱,每个箱子里包含特定的功能模块和物品,所有东西可以很灵活地拆分出来。换言之,在单点服务中,所有的部件都在一个巨大的软件包中。在微服务架构下,有很多独立存在的小服务,通过 API 接口连接成庞大的系统。

  表面上看来,微服务架构模式有点像SOA,他们都由多个服务构成。但是,可以从另外一个角度看此问题,微服务架构模式是一个不包含Web服务(WS-)和ESB服务的SOA。微服务应用乐于采用简单轻量级协议,比如REST,而不是WS-,在微服务内部避免使用ESB以及ESB类似功能。微服务架构模式也拒绝使用canonical schema等SOA概念。

微服务架构原来应用开发还可以这么美好

  微服务架构下,技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状,自由选择最适合的技术栈。由于每个微服务相对简单,当需要对技术栈进行升级时所面临的风险较低,甚至完全重构一个微服务也是可行的。当某一组建发生故障时,在单一进程的传统架构下,故障很有可能在进程内扩散,形成应用全局性的不可用。在微服务架构下,故障会被隔离在单个服务中。若设计良好,其他服务可通过重试、平稳退化等机制实现应用层面的容错。

  使用微服务构建适合云的新型应用是很有意义的,因为它让你既利用了横向扩展架构,也利用了纵向扩展架构,还额外得到API的组合,且在整个业务中可重复利用。可能在每一分钟都在交付新服务,这样你就会拥有一个敏捷的且即时响应的应用程序平台,当然这一平台一直在不断改进中,微服务架构也在前进着。

0
相关文章