微服务概述
2019-11-11 14:10:41 0 举报AI智能生成
微服务理解和概述，简单清楚的了解什么是微服务、在日常项目中，那些属于微服务。垂直模式和微服务模式的区别是什么等。
作者其他创作
大纲/内容
什么是微服务
1、微服务是一种架构风格(模式)
2、微服务的目标就是将原有的复杂且大型的单体应用按照业务或模块等规则进行拆分
3、让每一个拆分的独立且小型应用服务专注单一业务功能并对外提供服务
4、每一个独立的小型应用可以独立编译及部署，同时各模块简相互通信来协作，组合为整体对外提供服务
5、由于每一个独立的服务模块都独立部署，各自拥有互不干扰的内存空间。模块之间不能直接进行通信。
需要借助RPC(远程过程调用协议)或Http协议让各个模块之间传递通信报文及交换数据，实现远程调用。
整个通信管理的过程也是微服务架构重要组成部分。
微服务的案例
形象的比喻
1、微服务就像是活字印刷术，每一个文字模都可以看成是一个微服务，它可以独立的提供应刷服务，
又可以将模块之间组合，最终形成一篇完整文章提供更为复杂的印刷服务
https://www.zhihu.com/question/65502802/answer/802678798?utm_source=wechat_session&utm_medium=social&utm_oi=26761546956800
垂直应用与微服务
概述
MVC模式构建的垂直应用非常适合项目初期，使用其能够方便进行开发、部署、测试，但随着业务的发展与访问量的增加，
垂直应用的问题也随之暴露出来，而微服务架构可以很好的解决这些问题。
代码维护
垂直模式
1、大部分应用都部署在一个集中化、单一的环境或服务器容器中运行。
2、垂直应用程序通常很大，有一个大型团队或多个团队进行维护。
3、庞大的代码库可能个希望熟悉代码的开发人员增加学习成本。
4、在应用程序开发过程中使用开发环境工具和运行容器不堪重负，最终导致开发效率降低。
微服务模式
1、将庞大、复杂的应用拆分成多个逻辑简单且独立的小应用。
2、每个小应用交由不同的团队和开发人员维护，彼此互不干扰，通过标准的接口相互通信。
3、对于希望熟悉代码的开发人员来说只需要掌握他所负责的应用即可，这样简单、快速、逻辑清晰、易于维护。
部署
垂直模式
1、垂直应用需要处理一个庞大的应用程序，编译、部署都需要花费更长的时间。
2、一个小的逻辑或业务的修改肯跟导致重新构建整个项目。
微服务模式
1、微服务拆分的各个独立应用独立运行，代码量少、业务简单，编译快。
2、对其中某一个服务的修改，只需要重新编译、部署被改动的服务模块。
资源控制
垂直模式
1、当请求量过大导致单台服务器服务支撑时，一般会将最值应用部署在多台服务器形成的服务集群中。
2、通过反射代理实现负债均衡。
3、集群中的每一个服务必须部署完成的应用，但在实际业务需求中仅有部分功能使用频繁，但这种架构必须为不常用的功能分配计算资源。
4、例如在系统中的消息功能使用频率占了整个系统的90%，而密码找回功能则只占到20%。
为了分解消息功能的压力，以传统负债均衡的方式进行集群化时，每个服务必须为使用量为20%的密码找回功能分配资源，这无疑造成资源浪费。
微服务模式
1、微服务将提供功能的服务拆分成多个服务模块，具有天生的集群属性，能够给轻松地根据用量部署。
2、例如在服务中，消息功能使用率占据90%，则将消息模块多部署几个实例形成集群，而密码找回功能所在的用户模块只部署一个就可以了。
稳定
垂直模式
1、如果一个小问题，可能就会造成整个系统的崩溃
微服务模式
1、微服务所拆分出的各个模块中，由于模块之间的耦合度很低，当发生问题时的影响范围被固定在该模块本身，整个系统已让健全。
主流的微服务框架
Dubbo
1、由阿里巴巴2011年开源的Dubbo项目，2013年停止更新，2017年重启维护并发布新版本
2、Dubbo采用Zookeeper作为注册中心，RPC作为服务调用方式，致力提供高性能和透明化的RPC远程服务调用方案。
3、他与Spring服务集成，基于服务提供方(服务端)与服务调用方(客户端)角色构建简单模型，使用方便、学习成本低。
4、基本原理
1、服务提供方发布服务到服务注册中心
2、服务消费方从服务注册中心订阅服务
3、注册中心通知消息调用方服务注册
4、服务消费方调用已经注册的可用服务
5、监控计数
Spring Cloud
1、Spring Cloud基于Spring Boot实现
2、使用Http的RestFul风格API作为调用方式
3、它是由多个子项目共同构建了服务体系
1、Netflix Eureka
Spring Cloud的服务注册中心提供服务注册、服务发现、负载均衡等功能
2、NetFlix Hystrix
当某个服务发生故障之后，则出发熔断机制(Hystrix)向服务调用方返回结果标识错误，
而不是一直等待服务提供方返回结果，这样就不会使得线程因调用故障服务而被长时间占用不释放，避免了故障在分布式系统中的蔓延
3、Netflix Zuul
代理各模块提供的服务，统一暴露给第三方应用。提供动态路由、监控】弹性、全等的边缘服务。
4、Config Server
分布式架构下多微服务会产生非常多的配置文件，分布式配置中心(config server)将所有配置文件交由SVN或GIT记性统一管理，避免出错
5、Spring Boot
在使用Spring开发时，通常需要完成Spring框架及其他第三方工具配置文件的编写，非常麻烦。Spring Boot通过牺牲项目的自由度来减少配置的复杂度，约定一套规则，把这些框架都自动配置集成好，从合格到达“开箱即用”。
微服务的拆分
概述
微服务架构中拆分模块的基本逻辑，更为万三的模块拆分可以基于领域驱动设计(Domain Driven Design,DDD)进行
1、才分逻辑
概述
1、模块拆分是分布式微服务实施时的困难之一，它将直接影响到系统的复杂度、团队协作、代码维护难度、硬件资源分配等方面
2、模块拆分的越细，则能够更灵活地分配硬件资源与更方便地进行团队协作
3、同时也增加系统的复杂度与代码维护难度，在团队人数较少的情况下无疑增加了负担。
4、拆分模块需要以具体的业务需求与系统请求压力分布为出发点进行权衡取舍
系统复杂度
1、业务的复杂性决定了被拆分的模块之间必然存在一定的依赖
2、模块被拆分得越细就意味着会产生更多的依赖关系，在拆分解耦的同时必然意味着产生更多的依赖关系。在拆分解耦的同时必然增加了整个系统的复杂度
3、随着业务的丰富不可避免地使用系统，越来越复杂，我们没有办法拒绝复杂但通过规范、约定框架等手段尽量做到机构及代码的清晰与整洁。
团队协作
1、在垂直模式中，一般会使用Maven的多模块依赖特性将单一的应用拆分成多个模块，每个模块分给不同的工程师维护、最终团队提交模块，进行依赖管理打包发布。
2、为服务天生由多个模块组成，各个模块交由具体的专人负责，团队之间通过谋爱所暴露的服务进行写作，拆分模块的同时也确定团队协作方式。
代码维护难度
1、微服务能够解决在垂直应用中错综复杂的业务逻辑耦合在一起的维护困难问题，单页并不是将模块拆分得越细越好，过多则增加工作量与代码维护难度
2、每个模块都处理着处于自己的业务逻辑，他们提供服务并维护着与其他模块的依赖关系，如果服务提供方的返回结构发生变动，则各个调用方均要修改自己的代码。
3、在实际开发中不可避免要跨模块调试，调试过程中所涉及的模块数量越多，则整个过程就越麻烦
硬件资源分配
1、系统中存在请求压力不均衡的情况，模块拆分的越细，则能更有针对性地为高压力模块分配更多的计算资源，避免浪费
2、单模块
1、为了涉及处低耦合、高内聚的系统，需要确保各个模块都具有一定的独立性。
2、每个模块只完成它所负责的业务功能，并且模块之间做到最少联系及结构简单。
3、单个模块内聚了相关性较强的功能，并且拥有独立的数据(ORM)、单元测试、运行内存、业务逻辑处理等。可以将单个模块看成一个完成的垂直应用。
4、大部分请求都是同步的，及消费方发起请求后等待提供方万恒计算并返回结构，但如果等待的过程过于漫长，则需要借助消息队列与回调将请求的过程变为异步。
5、消防方向服务提供方的消息队列中发送请求消息，服务方计算完成后调用消防方的方法通知结果。
3、基础模块
1、一个复杂的业务功能需要依赖多个模块所提供的功能实现，在进行模块拆分时需要提前对业务所涉及的模块进行梳理
2、各个模块提供的服务具有一定的原子性，保持独立不重叠
3、将不需要依赖其他模块或较少的模块抽象为基础模块，为更为复杂的业务逻辑做准备，提供复用性与拓展性。
4、复杂模块
1、为了实现复杂业务将基础模块进行聚合重组时，每个模块对自身数据库操作事务管理比较简单。
2、但基于网络跨模块的二阶事务管理则会将整个过程变得无比复杂，并且耗费更多的资源。
3、在进行模块拆分时且尽量规避二阶事务的产生。在无法避免分布式事务的情况下，可以采用TCC(Trying Cofirming Canceling)补偿性事务解决方案实现对二阶事务的管理
4、例如：垂直应用在处理购物车或登录状态管理等功能时，一般会基于session实现，
但在分布式架构下Session的共享和传递会增加整个系统的耦合度并且提高复杂性。模块在处理自身业务逻辑及服务调用时，
尽量以无状态协议的角度进行设计，请求完立即释放资源。维护状态的工作可由服务提供方增加状态检查的服务，
但面对高查询、低修改的场景时可以基于约定交由公共缓存系统(Redis)维护。
0 条评论
下一页
