第一章 微服务架构开发:产生背景、优势、劣势、拆分原则、自治原则、交互原则、架构迁移

博客围绕Java开发中的单体架构和微服务架构展开。阐述了单体架构在开发、部署、运维等方面的困境,介绍了微服务架构的定义、优点和缺点,还提及微服务的拆分粒度以及不应使用微服务架构的情形,为架构选择提供参考。

1.1单体架构应用的困境

在java开发中,往往是将项目打包成war,部署到tomcat容器中,单体架构的缺点有哪些?

one, 随着业务扩张,开发、部署、运维会变得更难

tow,单体架构会越来越不稳定。一方面:不断增加的需求 另一方面:牵一发而动全身

three,单体架构应用很难接受或者切换到其它框架、语言

four,单体架构对开发者来说,需要了解更多的东西

five,部署上难以进行水平扩展

1.2 如何定义微服务

微服务架构从结构上来来看就是将一个应用拆分成多个松耦合的服务,这些服务之间通过某种协议(Rest,Rpc等)进行相互协作,完成单体架构下的业务功能,但提供更灵活的部署模式,更容易扩展,降低了开发、运维上的复杂度

微服务的核心思想就是 分而治之

 

1.3 微服务架构的优点

one,松耦合\独立    服务之间相互独立,编译打包部署各自为政、互不干涉

two,抽象   一个微服务对其数据结构和数据源具有绝对控制权

three ,应对需求多样性,微服务可以让我们轻松应对不同客户的特殊需求,通过定义良好的接口,可以让不同的微服务承担不同的职责,同时快速部署上线能力可以让用户需求尽早实现。

four,更高的可用性和弹性:微服务是一个去中心化的应用,每一个微服务都可以随时上线和下线。某个服务出现问题不会对其他服务造成影响

1.4 微服务架构的缺点

one,可用性降低,高度依赖于远程调用,一旦网络或者服务出现问题,将造成连锁反应

two,处理分布式事物复杂

three,全能对象阻止业务拆分,如电商的订单处理,很难单独拆成一个服务

four,学习难度大

five,部署复杂

微服务是一门艺术,市场上并没有最佳实践,要靠团队实践

 

1.5 微服务的拆分粒度

 

简单一句话,并不是越细越好,要把握尺度,往往取决于这个服务是不是承担的过多的职责

 

1.6不应使用微服务架构的情形

one ,构建分布式架构非常吃力时

tow,服务器蔓延时

three,采用小型应用、快速产品原型时

four,对数据一致要求高时

 

 

 

评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

知乎关注八戒来了

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值