单体架构还是微服务架构,这是个问题?

(此文章同时发表在本人微信公众号“dotNET每日精华文章”,欢迎右边二维码来关注。)

微服务架构现在越来越流行,那么是不是就意味着单体架构不再成为我们的选择了呢?个人认为这个要依情况而定。

现在谈及微服务架构的文章、演讲随处可见,似乎所有系统的架构都开始尽情拥抱微服务架构,包括笔者前久为一个异构电商平台系统设计的架构也选用了这种风格。然而,我们在选择微服务架构之前,一定要问一句“你现在面对的系统,微服务架构是一个好的选择吗?”。当然,这个问题也是我这几天在思考的。在我看来,任何互联网系统的架构发展到后期,随着复杂度越来越大,那么微服务架构是必然也是最好的选择。但是,正如《互联网系统架构的演进》提到的,系统的架构都是从小到大从简单到复杂演进的,“网站初期的架构一般采用“短平快”的架构思路,架构以简单清晰、容易开发为第一衡量指标。”

所以,微服务架构是否是一个好的选择,实际上要看系统的复杂度来决定的。对于这个问题,老马(Martin Fowler)最近发表的一篇文章《MicroservicePremium》深刻阐述了这一点。他给出了一个很关键的图:

上图直观的说明了单体架构和微服务架构在不同系统复杂度下不同的生产力,以及两者的对比关系。这篇文章谈到的很多具体内容,还需要读者自己去“阅读原文”。

综上,对于那种需要快速为商业模式提供验证的系统,其功能较少、用户很低的情况下,单体架构是更好的选择。不过,为了考虑未来的发展,一些基础性的功能(比如邮件发送之类)还是可以单独抽离封装为微服务的。且在单体架构内部,也需要更清晰的划分功能模块(尽量不让它们产生太强的耦合),数据库设计也可预先考虑未来微服务抽离的情况。

原文链接:http://martinfowler.com/bliki/MicroservicePremium.html

时间: 2024-08-02 15:10:32

单体架构还是微服务架构,这是个问题?的相关文章

Java高可用集群架构与微服务架构简单分析

前言 可能大部分读者都在想,为什么在这以 dubbo.spring cloud 为代表的微服务时代,我要还要整理这种已经"过时"高可用集群架构? 本人工作上大部分团队都是7-15人编制的开发团队,对应的公司项目也大都是中小型项目,最大的项目 PV/UV 也就只有 10w/2w .在这样的场景下,中小型公司一般都是创业起步没多久,大部分都需要本着"开源节流"."以最小的成本把产出最大化".微服务架构相比于高可用集群架构,个人理解,对于技术团队的成员

Android系统架构之微服务架构

目录 一.微服务架构模式 1.1 模式描述 1.2 模式拓扑 1.3 避免依赖与调度 1.4 注意事项 1.5 模式分析 二.Android中的微服务架构 三.结语 前段时间我们翻译的<软件架构模式>( 完整书籍的地址 ) 对外发布之后得到了大家的一致好评,书中讲述了五种经典.流行的软件架构模式,同时分析了五种模式的实现.优缺点等,为我们的开发工作提供了很有价值的指导.但是<软件架构模式>的问题在于没有结合具体的示例来让这些理论知识更易于吸收,因此有些同学在我的开发群反馈: 书看起

企业应用架构之微服务架构

微服务架构现在是谈到企业应用架构时必聊的话题,微服务之所以火热也是因为相对之前的应用开发方式有很多优点,如更灵活.更能适应现在需求快速变更的大环境. 本文将介绍微服务架构的演进.优缺点和微服务应用的设计原则,然后着重介绍作为一个"微服务应用平台"需要提供哪些能力.解决哪些问题才能更好的支撑企业应用架构. 微服务平台也是我目前正在参与的,还在研发过程中的平台产品,平台是以SpringCloud为基础,结合了普元多年来对企业应用的理解和产品的设计经验,逐步孵化的一个微服务应用平台. 目录:

Java高级架构:微服务架构的核心概念

微服务现在辣么火,业界流行的对比的却都是所谓的Monolithic单体应用,而大量的系统在十几年前都是已经是分布式系统了,那么微服务作为新的理念和原来的分布式系统,或者说SOA(面向服务架构)是什么区别呢? 我们先看相同点: 需要Registry,实现动态的服务注册发现机制: 需要考虑分布式下面的事务一致性,CAP原则下,两段式提交不能保证性能,事务补偿机制需要考虑: 同步调用还是异步消息传递,如何保证消息可靠性?SOA由ESB来集成所有的消息: 都需要统一的Gateway来汇聚.编排接口,实现

软件架构设计学习总结(22):软件架构——分层架构、事件驱动架构、微内核架构、微服务架构、基于空间的架构

分层架构 (Layered Architecture) 分层架构是最常见的架构,也被称为n层架构.多年以来,许多企业和公司都在他们的项目中使用这种架构,它已经几乎成为事实标准,因此被大多数架构师.开发者和软件设计者所熟知.比如MVC. 分层架构的一个特性就是 关注分离(separation of concerns) .在层中的组件只负责本层的逻辑.组件的划分很容易让它们实现自己的角色和职责,也比较容易地开发,测试管理和维护. 我们需要这样的冗余,即使业务层没有处理业务规则,也要通过业务层来调用数

孢子框架-网络游戏架构与微服务架构简单对比

笔者十年前做过网络游戏,当第一次看到微服务架构就发现它和网络游戏架构很像,如下图: 先来简单介绍一下这个网游架构,有些东西记不清了,如今的网游大牛看到可别丢砖头. 用户下载网游客户端,登录网游,首先会执行登录服务,登录服务主要就是给你分配一个网关,因为网关后面连接的才是真正的游戏服务器.登录后,进入游戏,发出指令,比如你移动到某个位置,这个指令会先发送到网关,然后再由网关识别发送到“移动系统”服务,移动系统计算后再经由网关发送给玩家客户端,玩家客户端执行一个动画让你移动到某个位置. 假如子服务间

SOA 架构与微服务架构的区别

注重重用,微服务注重重写 SOA 的主要目的是为了企业各个系统更加容易地融合在一起. 微服务通常由重写一个模块开始.要把整个巨石型的应用重写是有很大的风险的,也不一定必要.我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始. 把它们一个一个剥离出来用敏捷地重写,可以尝试最新的技术和语言和框架,然后 单独布署.它通常不依赖其他服务.微服务中常用的 API Gateway 的模式主要目的也不是重用代码. 而是减少客户端和服务间的往来.API gateway 模式不等同与 Fac

微服务架构(Microservice Architecture)

之前一段时间,有听部门架构说起接下来公司要使用微服务架构来研发系统,当时没怎么在意,因为是第一次听说微服务这个名词(果然无知者无畏啊):正好赶上五一假, 我自告奋勇的,接了编写微服务架构培训文档这个任务(也许因为我是文科生,文笔稍微好点).五一假期三天,基本都是在看资料,梳理思路以及编写接下来的培训文档中度过. 下面,就说说我这几天的一些收获吧:先说说资料来源吧:有架构给我的一些资料,以及自己百度和论坛.社区找来的一些资料,权当做一个总结式的简介... 目录如下: 一.微服务架构介绍 二.出现和

微服务架构的设计和实践-培训感悟

这两天(4月8号,9号)我有幸参加了极客邦的培训课程-微服务架构的设计和实践,能够面对面倾听58架构师-孙玄的亲身授课,个人也是感到非常的荣幸.两天的时间,来回于广州和深圳,虽然不能说自己的技术有了一个质的提升,但至少也是一次很好的交流体现,这一趟不白走! 身为一个技术小白(虽然个人也有四年的开发经验,但大多的技术只是知其然而不知其所以然,而且接触面太狭隘),此次学习最明显的感受是,如果你只会写软件代码,了解与某种语言相关的语法,框架以及架构包括技术,那你肯定会"死的很惨".作为软件行