为什么会产生微服务架构?

更新日期: 2019-08-29阅读: 1.8k标签: 微服务

Web应用架构受系统用户量、开发人员组织方式影响严重。过去二十年互联网迅速发展,Web架构也从单体式演进出微服务,背后还有比如 Martin Fowler 提出的理论支撑。虽然每个人都听说过微服务,但是很多人并不太清楚为什么要这么做,应该怎么做,怎么拆。要回答这个问题我认为需要从Web架构的演化历史的高度去理解这些架构设计中的取舍。

首先我们改进系统架构的目的是为了满足系统可靠性、并发量以及快速开发的需求。所有的改进方案都是为了解决这其中一个或多个问题而产生的。


单体结构


最开始Web服务器、数据库全部部署在同一台服务器上,这也是最简单的应用架构,通常公司早期项目都采用这种方式。在很长一段时间里单体结构可以满足系统快速开发与并发量的需求。当用户量越来越大,通常会数据库性能会成为系统瓶颈,此时可以将Web业务与数据库部署在不同服务器上,增强数据库服务器的配置并做读写分离等提高系统的吞吐量与可用性。

与此同时也可以将业务系统等价部署在多台服务器上来提高系统吞吐量,但整体上这仍然是一个单体应用。


随着用户、数据量进一步增大,单体应用的缺点会进一步显露出来,比如:

  • 耦合严重、复杂度高、可靠性差 :单体应用越来越来很多业务会耦合在一起,一但某些模块出现Bug会影响整个系统正常运行,业务代码的耦合也会形成开发人员的依赖造成新业务难以推进
  • 增加技术债、部署困难效率差 :技术债越来越多容易会造成“不坏不修“的囧境,已完成的代码难以被修改以防止系统某个地方意料之外的调用。同于由于代码量大导致应用全量部署困难
  • 系统吞吐量受限、阻碍技术进步 :单体应用难以进一步扩展使系统吞吐量受限,同时单体应用要求使用统一技术平台或解决方案,要想引入新语言或框架会非常困难


拆分

应用规模越来越大,首先遇到瓶颈的可能就是数据库系统,面对数据库压力通常我们可以对数据库做拆分把负载分担到不同的服务器上来解决,通常数据库拆分有两种方案:

  • 垂直拆分:对不同的业务系统如账户、搜索、推荐系统使用不同的数据库
  • 水平拆分:对于大表,比如十亿百亿级别的,进行多表拆分

数据库水平拆分与业务逻辑耦合紧密,需要具体问题具体分析,通常这是一个非常复杂的问题。后来人们引入 NoSQL、NewSQL 用分布式概念在数据库层屏蔽掉数据库的水平拆分,比如 NoSQL 的 MongoDB Sharding,NewSQL 的 TiDB。

同样的在业务层上我们也可以通过垂直拆分和水平拆分将单体业务拆成不同的服务,服务之间通过约定好的协议通信,以提高人员开发效率,实现多机部署冗余部署来提高系统可用性与吞吐量。


微服务

我们都知道微服务是一种提倡将单一服务拆分成一组小服务、服务之间相互协调、配合,提高开发效率,最终为用户提供价值的思路。说到微服务那么这里面最重要的一个问题就是服务应该怎么拆。微服务作为 SOA(Service Oriented Architecture)思想的一种具体实践我们首先想到的就是按照不同的业务系统做垂直拆分,如下图所示:


按业务系统对单体应用做垂直拆分,不同的业务线完全可以独立配备产品经历与工程师同步开发维护,将不同业务线解耦出来有不同团队维护。但上图是一种理想情况,各系统拆分力度比较大,系统之间不需要更详细的通信。如果是被拆除出了的子系统之间有大量的数据交互与调用,网关模式便不是一种很好的实践,通常会将各业务子系统接入一个数据总线用 ESB(Enterprise Service Bus)模式来进行数据交互,各子系统与数据总线进行数据交换便需要对子系统做统一管理,这遍有了 服务治理 的概念,用一套统一的保准来处理各子系统的注册、权限、监控等,目前有很多 ESB 开源或闭源的解决方案,这里不再赘述。

垂直拆分将各业务子系统解耦出来,但是每次请求在不同阶段遇到的瓶颈与负载是不一样的,因此我们对可以使用水平拆分的思路对服务进行拆分:


首先用户请求通过http协议到达网关,网关将json数据格式转为protobuf,通过tcp长链接与服务层、数据层通信获取目标数据然后返回给用户。这样拆分加长了用户请求链路时延,但是如果服务全部部署在同一内网,而且使用protobuf格式通信那么这个时延在几十毫秒内是完全可以接受的。业务层与数据层完全解耦便可以轻松将不同类型的服务进入冗余部署,同时在不动业务层的同时修改它的数据存储方式。

如果我们对系统即做垂直拆分也做水分拆分,那么就有了微服务的样子,


每级服务只能调用比他低级别的服务,如果搜索服务层只能掉账户接口层服务而不能调账户服务层接口,这样可以用来避免服务A调用服务B,而服务B同时又调用了服务A的循环调用问题。但是这样的拆分粒度仍然不够的,比如搜索系统和推荐系统都要调用账户系统的一些基础查询、修改逻辑,那么需要在搜索与推荐的服务层两次实现同样的代码吗,这样显然是不合理了,任何不能复用的设计显然都是有问题的。如果通过编写SDK库提供Jar包的模式去实现这个功能呢?,显然也存在问题比如推荐系统是Python实现,而搜索系统是Java实现的呢?所以这里我们将每个子系统可共用代码部分也单独抽取出来作为一个服务。


这样拆分后的系统可以灵活部署,独立开发,并且各模块服务使用的技术栈相对独立不受限制。但是同时拆分也将系统的网络拓扑便的复杂,运维负担加重,服务间的依赖使得服务接口的调整成本非常高。服务增多的同时对服务治理的要求也更高,需要专门做服务的发现、注册、鉴权、监控等系统功能。

原文 https://www.timqi.com/2019/08/29/web-arch-progress/

链接: https://www.fly63.com/article/detial/5002

微服务化的不同阶段 Kubernetes 的不同玩法

作为容器集群管理技术竞争的大赢家,Kubernetes已经和微服务紧密联系,采用Kubernetes的企业往往都开始了微服务架构的探索。然而不同企业不同阶段的微服务实践面临的问题千差万别,注定要在技术路线上产生分叉

微服务架构下的监控需要注意哪些方面?

微服务本身并没有一个严格的定义,不过从很多人的反馈来看,大家都达成了这样一个共识:微服务是一种简单的应用,大概有10到100行代码。我知道使用代码行数来比较实现其实很不靠谱,因此你能理解这个意思就行,不必过分拘泥于细节

微服务架构之「 调用链监控 」

「 调用链监控 」是在微服务兴起后才有的一种新流行的监控模式。因为在我们传统单体应用的项目中,不存在服务链/调用链的概念,所以也就根本没有调用链监控的需求了

一个知名网站的微服务架构最佳实现

在Medium,我们的技术堆栈始于2012年的单体Node.js应用程序。我们已经构建了几个卫星服务,但我们还没有制定一个系统地采用微服务架构的策略。 随着系统变得越来越复杂并且团队不断发展

采用微服务架构的六个考量因素

新兴技术的下一波浪潮正向我们涌来,人工智能、可穿戴设备、物联网及更多技术变得普及开来。许多组织现面临着管理这些整体式应用程序这个难题。当下,速度和灵活性必不可少

最终,我们放弃了微服务

微服务被认为是一种理想的架构模式,因此,Steven Lemon 所在公司的领导层决定从单体架构向微服务架构迁移,这让整个开发团队在随后的的日子里苦不堪言,七大现实问题摆在面前无法解决,微服务架构的好处也没有享受到

微服务架构如何影响软件开发文化?

微服务,并不仅仅是一种代码构造方式。微服务概念一出现就引发了热烈讨论,很多文章都喜欢将其与整体式架构比较,乃至来自大型企业的用例等。然而,在说起微服务时,开发人员关注的往往是这场革命的技术意义

PHP微服务集群搭建

近些年微服务架构大行其道,趁着最近有时间,来捣鼓捣鼓微服务是怎么一回事。微服务的概念由 Martin Fowler 于2014年3月提出:微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间相互协调

「微服务架构」基于Nginx的三种微服务参考架构

NGINX从一开始就参与了微服务运动。 NGINX的轻巧,高性能和灵活性非常适合微服务。NGINX Docker映像是Docker Hub上排名第一的应用程序映像,您今天在Web上找到的大多数微服务平台都包含一个演示

微服务开发的 10 个最佳实践

微服务架构是将软件系统分解成可独立部署的自治模块,这些模块通过轻量级的、语言无关的方式进行通信,共同实现业务目标。软件系统是复杂的。由于人脑只能处理一定程度内的复杂性

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!