中国领先的IT技术网站
|
|

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

相对于单体(Monolithic)应用而言,微服务是采用一组服务的方式来构建一个应用,服务独立部署在不同的进程中,不同服务通过一些轻量级交互机制来通信。

作者:张存来源:it168网站|2017-10-28 23:13

Tech Neo技术沙龙 | 11月25号,九州云/ZStack与您一起探讨云时代网络边界管理实践


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

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

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

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

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

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

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

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

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

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

【编辑推荐】

  1. 一线Python运维开发带你秒懂Flask框架
  2. Facebook宣布明年5月1日举办F8 2018开发者大会
  3. 2017 Linux Kernel 开发报告 Linux 在统治着计算机世界
  4. 娱乐开发两不误,10大开源游戏框架推荐
  5. 腾讯熊普江:20年老司机眼中的微服务架构优势及痛点
【责任编辑:赵宁宁 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

程序员密码学

《程序员密码学》涉及密码学的各个研究方向,分组密码、散列函数、公钥密码以及相关的攻击,同时也讲解了密码学算法实现上常用的ASN.编码、...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊
× Phthon,最神奇好玩的编程语言