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

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

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

 

单体架构

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

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

 单体架构--面临的挑战

• 维护和 升级 困难

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

• 系统可靠性变差

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

团队协作效率变差

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

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

 

集中式架构SOA

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

特点：

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

2、各各项目（系统）与服务之间采用webservice、rpc等方式进行通信。

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

优点：

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毕竟不是为服务网关设计出来的，

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

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

 

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

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