微服务应用开发入门①web端架构演进

从web层架构的演进了解微服务的概念,进而对微服务的组件有一定的了解;

从而知道为什么需要这些组件,以及这些组件设计的初衷,了解组件的责任和边界

 

单体架构

最早的时候,带宽所限,一个tomcat就可以搞定一个网站或者项目;MVC架构非常流行

即使在现在一些简单的网站和项目也可以使用nginx + tomcat;因为这样开发和维护成本比较低;

 单体架构--面临的挑战

维护和 升级 困难

        代码不断膨胀、功能越来越复杂、代码修改牵一发而动全身

系统可靠性变差

       访问量增加、软件和硬件都面临挑战、雪崩效应

团队协作效率变差

       重复代码增多,重复造轮子、测试变的复杂

  • 复杂应用的开发维护成本变高、部署效率变

 

集中式架构SOA

SOA架构一度也非常流行,能解决我们在单体架构中存在的问题。可以看到企业总线类似于服务网关的作用。

特点

1、基于SOA的架构思想将重复公用的功能抽取为组件,以服务的方式给各系统提供服务。

2、各各项目(系统)与服务之间采用webservicerpc等方式进行通信。

3ESB企业服务总线作为项目与服务之间通信的桥梁

优点:

1、将重复的功能抽取为服务,提高开发效率,提高系统的可重用性、可维护性。

2、可以针对不同服务的特点制定集群及优化方案。

3、采用ESB减少系统中的接口耦合。

缺点:

1、系统与服务的界限模糊,不利于开发及维护。

2、虽然使用了ESB,但是服务的接口协议不固定,种类繁多,不利于系统维护。

3、抽取的服务的粒度过大,系统与服务之间耦合性高

 

 集中式架构SOA-面临的挑战

SOA架构解决了应用服务化的问题、随着服务化的越来越深入、服务规模越来越大、服务治理面临的挑战也越来越多

  • 服务框架如何支持线性扩展
  • 分布式框架下的服务调用性能
  •  如何查看日志,快速定位和解决故障      
  • 服务限流、重试、超时控制、服务失败策略
  • 如何实现分布式服务监控
以上问题都期待我们有一个架构可以解决它,微服务架构风格应运而生。
 

微服务架构

微服务架构的特点

微服务架构实现阿里Dubbo

注册中心(registry):生产者在此注册并发布内容,消费者在此订阅并接收发布的内容。

消费者(consumer):客户端,从注册中心获取到方法,可以调用生产者中的方法。

生产者(provider):服务端,生产内容,生产前需要依赖容器(先启动容器)。

容器(container):生产者在启动执行的时候,必须依赖容器才能正常启动(默认依赖的是spring容器      

监控中心(monitor):dubbo提供的一个jar工程。主要功能是监控服务端和消费端的使用数据。

:服务端是什么,有多少接口,多少方法,调用次数,压力信息等,客户端有多少,调用过哪些服务端,调用了多少次等。

微服务架构实现SpringCloud 

基本步骤

1、启动服务将服务注册到注册中心     

2、启动服务网关注册到注册中心

3、服务之间的调用使用一般用feign

4、外部的流量通过服务网关负载均衡


还有淘宝的HSF和亚马逊的Coral Service、华为在电信行业的DSF等等

微服务功能特性

微服务化的优势 ---- 拥抱变化
  单一职责

       单一职责,这样能聚焦一个指定的业务功能或业务需求。

       开发简单、开发效率提高,一个服务可能就是专一的只干一件事。

       微服务能够被小团队单独开发,利于敏捷交付

服务 自治

        一个服务就是一个独立的实体

        微服务是松耦合的,是有功能意义的服务,无论是在开发阶段或部署阶段都是独立的

        微服务允许你利用融合最新技术和不同的言语(要考虑维护和规范)


微服务化的挑战----管理复杂度

  服务 的拆分和定义是一项 挑战

        康威定律

分布式 系统带来的各种复杂性

       运维以及监控 服务升级、版本控制; 

       超大型分布式系统需要考虑性能问题和更复杂的存储、监控和运维等

 

 

l MVC 架构 业务规模很小时,将所有功能都部署在同一个进程中,通过双机或者前置负载均衡器实现负载分流

 

l SOA 架构: 随着业务发展,服务数量越来越多,服务生命周期管控和运行态的治理成为瓶颈,此时用于提升服务质量的 SOA 服务治理是关键

 

l 微服务架构: 随着敏捷开发,持续交付, DevOps 理论的发展和实践,以及基于 Docker 等轻量级容器部署应用和服务的成熟,微服务架构开发流行,逐渐成为应用架构的未来演进方向。
 
 

个人寄语

技术是为了解决问题而存在的。

架构不是一成不变的,不是说定义了单体架构,SOA架构,就一直是这样;

架构是为了解决问题而慢慢演变的一个过程。其实还有RPC框架;有环境的因素和实际需求共同推动。

架构是一个逐步演变的过程,soa架构也可能发展出注册中心;

就比如esb企业总线和服务网关的概念去趋同的;

比如我2014-2016在项目中的架构使用MQ、可以算是伪分布式架构。

但是从整体上它并不是微服务架构,从架构层面上它不满足当前互联网项目发展的需要;

从个体层面上。esb毕竟不是为服务网关设计出来的,

他有他的历史任务,所以已当前的眼光来看,它是落后的;以当时的眼光来看来看他是一个合适

的解决方案,是满足当时所需的是优秀的

 

所以重申一下个人观点,技术是为了解决问题而存在的,我们不能说什么技术流行就用什么技术;

我们应该看来这个技术解决了什么问题,然后看看它是否能解决我们的问题;

 
 
 

 

 
评论 7
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值