一、微服务简介微服务的诞生微服务是基于分而治之的思想演化而来的。过去传统的大型综合系统，随着互联网的发展，已经难以满足市场对技术的需求，所以我们从单体架构发展到分布式架构，从分布式架构发展到分布式架构。一个SOA架构，随着服务的不断拆分和分解，粒度越来越小，直到微服务架构的诞生。微服务架构是一种架构模式，提倡将单个应用划分为一组小的服务，服务之间相互协调配合，为用户提供最终价值。每个服务都运行在自己独立的进程中，服务之间使用轻量级通信机制（通常是基于HTTP的RESTfulAPI）进行通信。每个服务都围绕特定的业务构建，可以独立部署到生产环境、类生产环境等。另外，要尽量避免统一集中的服务管理机制。对于具体的服务，要根据业务上下文选择合适的语言和工具来构建。微服务架构和SOA架构的区别微服务是真正分布式和去中心化的。把包括路由、消息解析在内的所有“会思考”的逻辑都放在服务内部，去掉一个统一的ESB，服务之间轻通信，是比SOA更彻底的拆分。微服务架构的重点是业务系统需要彻底的组件化和服务化。将原来单一的业务系统拆分成多个可以独立开发、设计、运行和维护的小应用。这些小应用程序通过服务连接完成交互和集成。微服务架构带来的问题由于整个业务数据分散在各个子服务的背后，也带来了两个最明显的问题。业务管理系统查询数据完整性，如分页查询、多条件查询等，拆分后的数据如何整合？数据分析和挖掘，这些需求可能需要对全量数据进行分析，而且分析不能从技术上影响到当前业务的解决方案，我们一般有两种方案来处理这些问题。第一种是在线处理数据，第二种是离线处理数据。在线数据处理方案：通过微服务提供的接口获取数据，然后进行数据整合。但是这种方式有明显的缺点，就是调用者需要编写大量的数据处理代码。其次，从各个微服务中获取数据时，会影响微服务正常的业务处理性能。离线数据处理方案：将业务数据准实时同步到另一个数据库，同步过程中进行数据集成处理，满足业务方对数据的需求，数据同步后，提供另一个服务接口负责向外界输出数据信息。该方案有两个特点：①数据同步方案是关键，技术选择较多。如何选择适合公司业务的技术解决方案；②离线数据处理不影响微服务的正常业务处理。推荐使用第二种方法。使用SpringBoot和MongoDB可以轻松解决这个问题。通过技术手段，将拆分成N个微服务的数据同步到MongoDB集群中，在同步过程中对数据进行清洗，以满足公司的需求。微服务架构中的一个业务需求存在较大的问题，即服务故障的传播、服务的划分、分布式事务。2.CAP理论一致性：指数据的强一致性。如果某条数据写入成功，再读取，则将读取所有新写入的数据；如果写入失败，后续读取的将不是写入失败的数据。Availability：指服务的可用性Partition-tolerance：指分区容错。P是分布式系统中的基本需求，而单体服务是CA系统，微服务系统通常是AP系统，既满足可用性又满足分区容错。这就提出了一个难题：分布式系统中如何保证数据的一致性？这就是大家经常讨论的分布式事务。3、分布式事务在微服务架构中，类分布式事务的解决方案是两阶段提交或三阶段提交。无论使用哪种方式，都会出现事务失败，导致数据不一致。关键时刻，不得不手动恢复数据。第一阶段：发起分布式事务，交给事务协调器TC处理。TC向所有参与交易的节点发送处理交易操作的准备操作。所有参与节点执行准备操作，将Undo和Redo信息写入日志，并返回给事务管理器准备操作是否成功。第二阶段：事务管理器收集所有节点的准备操作是否成功，如果成功则通知所有节点执行提交操作；如果失败，执行回滚操作什么是分布式微服务架构？三分钟搞懂什么是分布式和微服务两阶段提交。将事务分成两部分可以大大提高分布式事务成功的概率。如果stage成功了，但是stage中有一个节点出现故障，数据还是不准确，此时一般需要人工处理，这也是第一步记录日志的原因。另外，如果一个分布式事务涉及到很多节点，某个节点的网络出现异常会导致整个事务被阻塞，大大降低数据库的性能。所以一般情况下，尽量少用分布式事务。4.服务事业部横向拆分：按照订单、营销、风控、积分资源等不同业务领域进行拆分。形成一个独立的业务域微服务集群。垂直拆分：拆分业务功能中的不同模块或组件。比如将公共组件拆分成独立的原子服务，下沉到底层，形成一个相对独立的原子服务层。这样就可以实现业务的服务拆分，纵向和横向。做好微服务的分层工作：梳理提取核心应用和公共应用，作为独立服务下沉到核心和公共能力层，逐步形成稳定的服务中心，让前端应用响应更迅速以适应不断变化的市场需求总之，微服务的设计一定要循序渐进。总的原则是服务内部高内聚，服务之间低耦合。微服务的特点：按业务划分服务，单个服务代码量小，业务单一，易于维护。每个微服务都有自己独立的基础组件，如数据库、缓存等，运行在独立的进程中。微服务之间的通信使用HTTP协议或消息组件，具有容错能力。微服务有一套服务治理方案。服务不耦合，可以随时添加和删除单个微服务。它们可以集群部署，并且具备平衡整个微服务的能力。系统应具有完善的安全机制，包括用户认证、权限认证、资源保护等。整个微服务系统都具备追踪链接的能力。一个完整的实时日志系统给数据库带来了挑战。服务拆分后，我们遇到最大的问题就是后台管理的联合查询。每个微服务都有自己独立的数据库，那么后台怎么处理呢？一般有以下几种方法：严格按照微服务的划分，微服务之间相互独立，每个微服务的数据库也是独立的。当后台需要展示数据时，调用各个微服务的接口获取相应的数据，然后对数据进行处理。处理后显示，这是标准用法，也是最麻烦的用法。将业务关联度高的表入库，严格按照微服务模型拆分业务关系不太密切的表，让您可以使用微服务，避免因分散而难以实现后台系统的统计功能数据库。折衷方案。数据库按照微服务的要求严格划分，满足业务的高并发，每个微服务数据库的数据实时或准实时同步到NoSQL数据库，同步过程中进行数据清洗为满足后台业务系统的使用，推荐使用MongoDB、HBase等。这三种方案我在不同的公司都用过。第一种方案适合业务比较简单的小公司；第二种方案适用于在原有系统的基础上逐步向微服务架构演进的公司；第三种方案适合大型高并发的互联网公司。5.熔断器为了解决分布式系统的雪崩效应，分布式系统引入了熔断器机制。当某个服务在一定时间内未能处理用户请求的次数小于设定的阈值时，熔断器关闭，服务正常。当一定时间内服务处理用户请求失败的次数大于设定的阈值时，说明服务失败，熔断器开启。这意味着所有的请求都会很快失败，业务逻辑也不会被执行。熔断器开启后，经过一段时间后，处于半开状态，执行一定数量的请求。其余请求将很快失败。如果执行请求失败，熔断器会继续打开。如果成功，熔断器将被关闭。什么是分布式微服务架构？三分钟搞懂什么是分布式和微服务。熔断器不仅可以防止系统的“雪崩”效应，还具有以下功能：隔离资源和服务降级的功能。自愈能力6.服务网关在微服务系统中，API接口资源通常由服务网关（也称API网关）统一暴露，内部服务不直接对外提供API资源暴露。优点是内部服务隐藏，保护系统的安全网关层通常以集群的形式存在。Nginx通常加在服务网关层之前，对网关进行负载均衡的意思：网关统一聚合了所有服务的API接口资源，统一暴露网关可以进行一些用户身份认证和权限认证，防止非法请求操作API接口。保护内部服务网关可实现监控功能，实时日志输出，记录请求。网关可用于流量监控。在高流量的情况下，服务可以降级。API接口与内部服务分离，方便做测试当然网关需要高可用才能实现这些功能，否则网关很可能成为架构成功的瓶颈。最常用的网关组件是Zuul和Nginx，例如：SpringCloudConfig组件，阿里的Diamond，百度的Disconf，携程的Apollo等。八、服务链接跟踪在微服务架构中，必须实现分布式链接跟踪，跟进一个请求涉及到哪些服务，顺序参与是每个请求链接清晰可见，方便快速问题定位常用的链接跟踪组件有谷歌的Dapper，推特的Zipkin，阿里的鹰眼（Eagleeye）9.微服务框架市场上常用的微服务框架包括：SpringCloud,Dubbo,kubernetes什么是分布式微服务架构？三分钟搞懂什么是分布式和微服务。从功能模块来看，Dubbo缺少很多功能模块，比如网关，链路跟踪等。从学习成本来看，Dubbo版本趋向于稳定，稳定和完善，即学即用，简单易用，难度很简单，Springcloud是基于SpringBoot的，需要先掌握SpringBoot，例外Springcloud多为英文文档，要求学习者有一定的英文阅读能力考虑到开发风格，Dubbo倾向于使用XML配置方式，SpringCloud基于SpringBoot采用基于注解和JavaBean配置的敏捷开发。在开发速度上，SpringCloud具有更高的开发部署速度。在通信方式上，Springcloud是基于HTTPRestful风格，服务与服务之间是完全不相关的。无耦合。Dubbo基于远程调用，对接口、平台、语言的依赖性很强。如果需要实现跨平台，则需要额外的中间件。所以Dubbo专注于服务治理；SpringCloud专注于微服务架构生态。10、SpringCloudEureka常用组件：服务注册与发现组件Hystrix：熔断组件Ribbon：负载均衡组件Zuul：路由网关以上四个组件均来自Netflix，统称SpringCloudNetflixSpringCloudConfig：配置文件统一管理SpringCloudSecurity：SpringSecurity组件封装，提供用户验证和权限验证，一般与SpringSecurityOAuth2组一起使用，通过构建授权服务，验证Token或JWT来验证整个微服务系统的安全性SpringCloudSleuth：分布式链路追踪Components，封装了Dapper、Zipkin、Kibana的组件。SpringCloudStream：SpringCloud框架的数据流操作封装，可以封装RabbitMq、ActiveMq、Kafka、Redis等消息组件。使用SpringCloudStream，可以收发消息SpringCloud构建的一个简单的微服务系统，通常由服务注册中心Eureka、网关Zuul、配置中心Config和授权服务Auth组成什么是分布式微服务架构？三分钟全面了解什么是分布式和微服务SpringCloudNetflix特点：服务发现：Eureka实例可以注册，客户端可以使用Spring管理的bean来发现实例服务发现：嵌入式Eureka服务器可以使用声明式Java配置CircuitBreaker:Hystrix客户端可以使用简单的注解驱动的方法装饰器构建断路器：嵌入式Hystrix仪表板，带有声明式Java配置声明式REST客户端：Feign创建一个用JAX-RS或SpringMVC注释装饰的方法接口的动态实现。客户端负载均衡器：Ribbon外部配置：从Spring环境到Archaius的桥接（使用SpringBoot约定启用Netflix组件的本机配置）路由器和过滤器：Zuul过滤器的自动重新注册，以及反向代理创建的简单配置约定如果这个文章对你有帮助，别忘了给我3个链接，点赞、转发、评论，我们下期见！获取方式：点赞、评论、关闭~学习更多JAVA知识和技能，关注并私信博主(666)
