首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

微服务架构案例(01):项目技术选型简介,架构图解说明

一、单体架构 单体架构在中等偏小的业务中比较常见,场景模式就是单个应用、单个数据库。一个程序包(例如war格式或者Jar格式)包含所有业务需求功能,这是一种比较传统的架构风格。 单体架构的缺陷 复杂性高,整个项目包含的模块多,依赖模糊,修改程序容易触发不可知问题。 扩展能力受限,单体应用只能整体进行扩展,无法针对业务模块的特性进行伸缩。 稳定性差,任何微小的问题,都可能导致整个应用服务直接挂掉。 二、微服务架构 微服务架构是一种架构概念,核心思想在于通过将业务功能和需求分解到各个不同的服务中进行管理,实现对

02

颠覆微服务认知:深入思考微服务的七个主流观点

单体系统和微服务的区别在于,一个单体系统是一个大而全的功能集合,每个服务器运行的是这个应用的完整服务。而微服务是独立自治的功能模块,它是生态系统中的一部分,和其他微服务是共生关系。现在,业界对单体系统和微服务的普遍观点是:单体系统非常容易开发、测试、部署,但是单体系统面对的问题也很多,例如开发效率变低、维护成本增加、部署影响变大、可扩展性较差、技术选型成本高,而引入了微服务可以实现每个微服务易于开发与维护,便于沟通与协作,很适合小团队敏捷开发与持续交付;每个微服务职责单一,高内聚、低耦合。同时,每个微服务能够独立开发、独立运行、独立部署;每个微服务之间是独立的,如果某个服务部署或者宕机,只会影响到当前服务,而不会对整个业务系统产生影响;每个微服务可以随着系统规模的不断扩大,面对海量用户和高并发,独立做水平扩展与垂直扩展;每个微服务可以使用不同的编程语言以及不同的存储技术,使得我们更容易尝试新的技术。此外,对单个服务进行业务重构,也不会面临很大的业务负担与技术债券。

05
领券