架构演变及微服务理解

1、单机系统

        单体架构是今天绝大多数软件开发者都学习、实践过的一种软件架构,许多介绍微服务的图书和技术资料中也常把这种架构风格的应用称作“巨石系统”(Monolithic Application)。

        很多互联网产品在发展的初期业务量并不大,并不需要一来就采用分布式、云部署的复杂方案,用All-in-One的简单架构即可。

2、单机进阶 

        动静分离,进一步拆分文件服务和应用服务。

3、应用集群化部署

        进一步数据库读写分离 

        引入搜索和缓存 

        数据库分库分表 

4、微服务拆分 

        服务垂直拆分

         微服务架构

 5、服务网格

        服务网格不会向应用程序的运行时环境引入新功能——任何架构中的应用程序总是需要规则来指定请求如何从 A 点到达 B 点。服务网格的不同之处在于它采用了管理服务的逻辑——服务之间的通信从单个服务中提取出来,并将其抽象为基础设施层。

        服务网格是如何实现的呢?它通常会为每个服务实例提供一个称为边车(sidecar)的代理实例。这些边车会处理服务间的通信,监控和安全相关的问题,以及任何可以从各个服务中抽象出来的东西。这样,开发人员就可以专注于服务中应用程序代码的开发,支持和维护,而运维团队可以负责维护服务网格以及运行应用程序。  

6、总结

        许多互联网产品的业务是逐步拓展的,其架构也是跟随业务变化逐步演化的。

        实质上微服务架构是一种理念,不是一种技术,任何语言都可以自行实现这种架构。

        为什么推荐基于Java语言进行微服务框架内的应用开发,主要是因为java微服务周边生态的成熟度,有很多开箱即用的第三方服务可用(Spring Cloud)。

        微服务架构优势,(1)主要是服务界定清晰(把复杂的工作拆解为简单的单一服务)(2)不局限于语言技术等(3)每个微服务自由进行扩展。

        微服务架构劣势,(1)分布式系统带来的复杂性(2)多个数据库带来的复杂性(3)多个应用带来的部署、监控等等的复杂性(4)对于开发人员的要求更高。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

坐望云起

如果觉得有用,请不吝打赏

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

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

打赏作者

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

抵扣说明:

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

余额充值