微服务与微服务与SOA之间差了一个之间差了一个ESB
微服务只是最近提出的概念,实际上很多巨头公司(FB、Twitter、AWS等)已经在亲身实践。微服务并不是银弹,但是
我们可以参考它的思想来解决自己遇到的问题。对于已经找准市场,业务即将或者马上就要急剧发展的创业公司,适
合使用基于微服务的软件架构。
今天阅读了两篇关于微服务的文章,总结一些笔记,简单翻译了一篇文章。说明:并没有严格按照原文一字语句翻
译,有部分自己的理解,还有部分是意译。
微服务(micro services)这个概念不是新概念,很多公司已经在实践了,例如亚马逊、Google、FaceBook,Alibaba。
微服务架构模式(Microservices Architecture Pattern)的目的是将大型的、复杂的、长期运行的应用程序构建为一组相
互配合的服务,每个服务都可以很容易得局部改良。 Micro这个词意味着每个服务都应该足够小,但是,这里的小不能
用代码量来比较,而应该是从业务逻辑上比较——符合SRP原则的才叫微服务。
暂且不讨论大小问题,读者朋友你首先要考虑的是如何解决目前技术团队遇到的开发问题、部署问题。正是在解决这
些问题的过程中,才渐渐总结提炼出了微服务架构模式的概念。
微服务跟SOA有什么区别呢,可以把微服务当做去除了ESB的SOA。ESB是SOA架构中的中心总线,设计图形应该是
星形的,而微服务是去中心化的分布式软件架构。
接下来会讨论以下几个话题:
应用微服务的动机,跟传统巨石应用的比较
微服务的优点与缺点
应用微服务架构设计时可能遇到的关键问题(内部服务通信、分布式数据管理)
一、巨石(monolith)应用
web应用程序发展的早期,大部分web工程是将所有的功能模块(service side)打包到一起并放在一个web容器中运行,
很多企业的Java应用程序打包为war包。其他语言(Ruby,Python或者C++)写的程序也有类似的问题。
假设你正在构建一个在线商店系统:客户下订单、核对清单和信用卡额度,并将货物运输给客户。很快,你们团队一
定能构造出如下图所示的系统。
这种将所有功能都部署在一个web容器中运行的系统就叫做巨石型应用。巨石型应用有很多好处:IDE都是为开发单个
应用设计的、容易测试——在本地就可以启动完整的系统、容易部署——直接打包为一个完整的包,拷贝到web容器
的某个目录下即可运行。
但是,上述的好处是有条件的:应用不那么复杂。对于大规模的复杂应用,巨石型应用会显得特别笨重:要修改一个
地方就要将整个应用全部部署(PS:在不同的场景下优势也变成了劣势);编译时间过长;回归测试周期过长;开发效率降
低等。另外,巨石应用不利于更新技术框架,除非你愿意将系统全部重写(代价太高你愿意老板也不愿意)。
二、巨石应用的拆分
详细一个网站在业务大规模爬升时会发生什么事情?并发度不够?OK,加web服务器。数据库压力过大?OK,买更大更
贵的数据库。数据库太贵了?将一个表的数据分开存储,俗称“分库分表”。这些都没有问题,good job。不过,老外的
抽象能力比我们强,看下图Fig2。