标签：阅读 abi oauth enc 协议 uri OLE 阻塞 包括
微服务是基于分而治之的思想演化出来的。过去传统的一个大型而又全面的系统，随着互联网的发展已经很难满足市场对技术的需求，于是我们从单独架构发展到分布式架构，又从分布式架构发展到 SOA 架构，服务不断的被拆分和分解，粒度也越来越小，直到微服务架构的诞生。
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。
每个服务运行在其独立的进程中，服务和服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
微服务是真正的分布式的、去中心化的。把所有的“思考”逻辑包括路由、消息解析等放在服务内部，去掉一个大一统的 ESB，服务间轻通信，是比 SOA 更彻底的拆分。
微服务架构强调的重点是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间通过服务完成交互和集成。
随着整个业务数据被分散在各个子服务之后，也带来了两个最明显的问题。
从技术方案来讲，我们一般有两种选择来处理这些问题，第一种是在线处理数据，第二种是离线处理数据。
在线处理数据的方案：通过微服务提供的接口来获取数据，然后进行数据整合，不过这种方式有着明显的弊端，就是调用者需要编写大量的代码进行数据处理。其次在对各个微服务进行调取数据时会影响微服务的正常业务处理性能
离线处理数据方案：将业务数据准实时的同步到另外一个数据库中，在同步的过程中进行数据整合处理，以满足业务方对数据的需求，数据同步过来后，再提供另外一个服务接口专业负责对外输出数据信息，这种方案有两个特点：①数据同步方案是关键，技术选型有很多，如何选择切合公司业务的技术方案；②离线数据处理对微服务正常业务处理没有影响。
推荐使用第二种，利用 Spring Boot 和 MongoDB 可以轻松的解决这个问题，通过技术手段将分裂到 N 个微服务的数据同步到 MongoDB 集群中，在同步的过程中进行数据清洗，来满足公司的各项业务需求
在微服务架构中，有 大难题，那就是 服务故障的传播性 、 服务的划分 和 分布式事务 。
Consistency ：指数据的强一致性。如果写入某个数据成功，之后读取，读到的都是新 写入的数据：如果写入失败，之后读取的都不是写入失败的数据。
Availability ：指服务的可用性
Partition-tolerance ：指分区容错
在分布式系统中 P是基本要求，而单体服务是 CA 系统， 微服务系统通常是 AP 系统，即同时满足了可用性和分区容错。
这就有了 个难题：在分布式系统中如何保证数据的一致性？这就是大家经常讨论的 分布式事务
在微服务架构中，分布式事务 般的解决办法就是 两阶段提交 或者 三阶段 提交，不管使用哪都存在事务失败，导致数据不 致的情况，关键时刻还得人工去恢复数据。
两阶段提交，将事务分成两部分能够大大提高分布式事务成功的概率。如果在第 阶段都成功了，而执行第 阶段的某 个节点失败，仍然导致数据的不准确，这时一般需要人工去处 理，这就是当初在第一步记录日志的原因。另外，如果分布式事务涉及的节点很多，某 个节 点的网络出现异常会导致整个事务处于阻塞状态，大大降低数据库的性能。 所以一般情况下， 尽量少用分布式事务。
横向拆分：按照不同的业务域进行拆分，例如订单、营销、风控、积分资源等。形成独立的业务领域微服务集群。
纵向拆分：把一个业务功能里的不同模块或者组件进行拆分。例如把公共组件拆分成独立的原子服务，下沉到底层，形成相对独立的原子服务层。这样一纵一横，就可以实现业务的服务化拆分。
要做好微服务的分层：梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和公共能力层，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求
总之，微服务的设计一定要 渐进式 的，总的原则是 服务内部高内聚，服务之间低耦合。
随着服务拆分后，我们遇到最大的问题就是后台管理的联合查询，每个微服务都有自己独立的数据库，那么后台该怎么处理？
这里一般有如下几种方式：
三种方案在不同的公司我都使用过，第一种方案适合业务较为简单的小公司；第二种方案，适合在原有系统之上，慢慢演化为微服务架构的公司；第三种适合大型高并发的互联网公司。
为了解决分布式系统的雪崩效应，分布式系统引进了 熔断器机制 。
当一个服务的处理用户请求的失败次数在一定时间内小于设定的阀值时，熔断器出于关闭状态，服务正常。
当服务处理用户请求失败次数在一定时间内大于设定的阀值时，说明服务出现故障，打开熔断器，这是所有的请求会快速失败，不执行业务逻辑
当处于打开状态的熔断器时，一段时间后出于半打开状态，并执行一定数量的请求，剩余的请求会执行快速失败，若执行请求失败了，则继续打开熔断器，若成功了，则将熔断器关闭
熔断器不仅能防止系统的“雪崩”效应，还具有以下作用
在微服务系统中，API 接口资源通常是有服务网关（也称API网关）统一暴露，内部服务不直接对外提供API资源的暴露。好处在于隐藏内部服务，保护系统安全
网关层通常以集群的形式存在。并在服务网关层前通常会加上Nginx 用来负载均衡
网关意义：
当然，网关实现这些功能，需要做高可用，否则网关很可能成功架构的瓶颈，最常用的网关组件Zuul、Nginx
在微服务架构中，需要有统一管理配置文件的组件，例如：SpringCloud Config组件、阿里的Diamond、百度的Disconf、携程的Apollo等
在微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与、参与顺序，是每个请求链路清晰可见，便于问题快速定位
常用链路追踪组件有Google的Dapper、Twitter 的Zipkin，以及阿里Eagleeye(鹰眼)
市面常用微服务框架有：Spring Cloud 、Dubbo 、kubernetes
以上4个组件来自于Netflix 公司，统称为Spring Cloud Netflix
一个简单的Spring Cloud 构建的微服务系统，通常由服务注册中心Eureka、网关Zuul、配置中心Config和授权服务Auth构成
Spring Cloud Netflix功能：
感谢大家的阅读，如有错误之处欢迎指正！
想要阅读更多精彩内容，可以关注我的微信公众号：Java技术zhai，这是我的私人公众号，专注于Java技术分享，期待你的参与。
标签：阅读 abi oauth enc 协议 uri OLE 阻塞 包括
原文地址：https://www.cnblogs.com/lfs2640666960/p/12300585.html
