微服务技术框架有哪些

㈠ 主流的微服务架构有哪些

微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。

微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。

中文名

微服务架构

外文名

microservice

服务平台

Imixs-Workflow

属性

Seneca是构建微服务框架的工具

现状

当下最新的热门话题

快速
导航

现状 特点 服务平台 工具开发

概念

微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。[1]

现状

微服务作为一项在云中部署应用和服务的新技术已成为当下最新的热门话题。但大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。

企业和服务提供商正在寻找更好的方法将应用程序部署在云环境中，微服务被认为是未来的方向。通过将应用和服务分解成更小的、松散耦合的组件，它们可以更加容易升级和扩展，理论上是这样。

㈡ 什么是微服务架构主流的微服务如何实现

简单地说，微服务架构就是以业务域或业务功能为边界，将一个大而全的应用拆分为可以独立开发，独立部署，独立测试，独立运行的一组小的应用，并且使用轻量级，通用的机制在这组应用间进行通信。
主流的微服务包括：
1、SpringCloud

Spring Cloud , 来自Spring，具有Spring 社区的强大支撑，还有Netflix强大的后盾与技术输出。Netflix作为一家成功实践微服务架构的互联网公司在几年前就把几乎整个微服务框架栈开源贡献给了社区，这些框架开源的整套服务架构套件是Spring Cloud的核心。

- Eureka:服务注册发现框架；

- Zuul:服务网关；

- Karyon：服务端框架；

- Ribbon：客户端框架；

- Hystrix：服务容错组件；

- Archaius：服务配置组件；

- Servo：Metrics组件；

- Blitz4j：日志组件；

2、Dubbo

Dobbo是一个分布式服务框架，是阿里开放的微服务化治理框架，致力于提高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。其核心部分(官网)

- 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式；

- 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持；

- 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

Dubbo 也是采用全 Spring 配置方式，透明化接入应用，对应用没有任何 API 侵入，只需用 Spring 加载 Dubbo的配置即可，Dubbo 基于 Spring 的 Schema 扩展进行加载。当然也支持官方不推荐的 API 调用方式。

3、lstio

lstio 作为用于微服务聚合层管理的新锐项目，是Google、IBM、Lyft（海外共享出行公司、Uber劲敌），首个共同联合开源的项目，提供了统一的连接，安全，管理和监控微服务的方案。

目前首个测试版是针对Kubernetes环境的，社区宣称在未来几个月内会为虚拟机和Cloud Foundry 等其他环境增加支持。lstio将 流量管理添加到微服务中，并为增值功能（如安全性、监控、路由、连接管理和策略）创造了基础。

- HTTP、gRPC 和 TCP 网络流量自动负载均衡；

- 提供了丰富的路由规则，实现细颗粒度的网络流量行为控制；

- 流量加密、服务件认证，以及强身份声明；

- 全范围（Fleet-wide）的策略执行；

- 深度遥测和报告。

㈢ 目前比较流程的微服务开发框架是

1.Spring Boot

Spring Boot的设计目的是简化新Spring应用初始搭建以及开发过程，2017年有64.4%的受访者决定使用Spring Boot，可以说是最受欢迎的微服务开发框架。利用Spring Boot开发的便捷度简化分布式系统基础设施的开发，比如像配置中心、注册、负载均衡等方面都可以做到一键启动和一键部署。

2.Spring Cloud

Spring Cloud是一个系列框架的合计，基于HTTP（s）的RETS服务构建服务体系，Spring Cloud能够帮助架构师构建一整套完整的微服务架构技术生态链。



3.Dubbo

Dubbo是由阿里巴巴开源的分布式服务化治理框架，通过RPC请求方式访问。Dubbo是在阿里巴巴的电商平台中逐渐探索演进所形成的，经历过复杂业务的高并发挑战，比Spring Cloud的开源时间还要早。目前阿里、京东、当当、携程、去哪等一些企业都在使用Dubbo。

4.Dropwizard

Dropwizard将Java生态系统中各个问题域里最好的组建集成于一身，能够快速打造一个Rest风格的后台，还可以整合Dropwizard核心以外的项目。国内现在使用Dropwizard还很少，资源也不多，但是与SpringBoot相比，Dropwizard在轻量化上更有优势，同时如果用过Spring，那么基本也会使用SpringBoot。

5.Akka

Akka是一个用Scala编写的库，可以用在有简化编写容错、高可伸缩性的Java和Scala的Actor模型，使用Akka能够实现微服务集群。

6.Vert.x/ Lagom/ ReactiveX/Spring 5

这四种框架主要用于响应式微服务开发，响应式本身和微服务没有关系，更多用于提升性能上，但是可以和微服务相结合，也可以提升性能。



.Net相关微服务框架

1. .NET Core

.NET Core是专门针对模块化微服务架构设计的，是跨平台应用程序开发框架，是微软开发的第一个官方版本。

2.Service Fabric

Service Fabric是微软开发的一个微服务框架，基于Service Fabric构建的很多云服务被用在了Azure上。

3.Surging

Surging是基于RPC协议的分布式微服务技术框架，基于.NET Core而来。

4.Microdot Framework

Microdot Framework用于编写定义服务逻辑代码，不需要解决开发分布式系统的挑战，能够很方便的进行MicrosoftOrleans集成。

㈣ 微服务框架之Spring Cloud简介

在了解 Spring Cloud 之前先了解一下微服务架构需要考量的核心关键点，如下图：

对于以上等核心关键点的处理，不需要我们重复造车轮， Spring Cloud 已经帮我们集成了，它使用 Spring Boot 风格将一些比较成熟的微服务框架组合起来，屏蔽掉了复杂的配置和实现原理，为快速构建微服务架构的应用提供了一套基础设施工具和开发支持。

Spring Cloud 所提供的核心功能包含：

Spring Cloud架构图

Spring Cloud子项目

Spring Cloud 旗下的子项目大致可以分为两类：

如下：

1. Spring Cloud 与 Spring Boot

Spring Boot 可以说是微服务架构的核心技术之一。通过在 Spring Boot 应用中添加 Spring MVC 依赖，就可以快速实现基于 REST 架构的服务接口，并且可以提供对 HTTP 标准动作的支持。而且 Spring Boot 默认提供 JackJson 序列化支持，可以让服务接口输入、输出支持 JSON 等。因此，当使用 Spring Cloud 进行微服务架构开发时，使用 Spring Boot 是一条必经之路。

2. Spring Cloud 与服务治理( Eureka )

服务治理是 Spring Cloud 的核心，在实现上其提供了两个选择，即 Consul 和 Netflix 的 Eureka 。

Eureka 提供了服务注册中心、服务发现客户端，以及注册服务的 UI 界面应用。

在 Eureka 的实现中，节点之间相互平等，有部分注册中心“挂掉”也不会对整个应用造成影响，即使集群只剩一个节点存活，也可以正常地治理服务。即使所有服务注册节点都宕机， Eureka 客户端中所缓存的服务实例列表信息，也可让服务消费者能够正常工作，从而保障微服务之间互相调用的健壮性和应用的弹性。

3. Spring Cloud 与客户端负载均衡( Ribbon )

Ribbon 默认与 Eureak 进行无缝整合，当客户端启动的时候，从 Eureka 服务器中获取一份服务注册列表并维护在本地，当服务消费者需要调用服务时， Ribbon 就会根据负载均衡策略选择一个合适的服务提供者实例并进行访问。

Spring Cloud 通过集成 Netflix 的 Feign 项目，为开发者提供了声明式服务调用，从而简化了微服务之间的调用处理方式。并且默认 Feign 项目集成了 Ribbon ，使得声明式调用也支持客户端负载均衡功能。

4. Spring Cloud 与微服务容错、降级( Hystrix )

为了给微服务架构提供更大的弹性，在 Spring Cloud 中，通过集成 Netflix 下子项目 Hystrix ，通过所提供的 @HystrixCommand 注解可以轻松为我们所开发的微服务提供容错、回退、降级等功能。此外， Hystrix 也默认集成到 Feign 子项目中。

Hystrix 是根据“断路器”模式而创建。当 Hystrix 监控到某服务单元发生故障之后，就会进入服务熔断处理，并向调用方返回一个符合预期的服务降级处理（ fallback ），而不是长时间的等待或者抛出调用异常，从而保障服务调用方的线程不会被长时间、不必要地占用，避免故障在应用中的蔓延造成的雪崩效应。

而 Hystrix 的仪表盘项目（ Dashboard ）可以监控各个服务调用所消耗的时间、请求数、成功率等，通过这种近乎实时的监控和告警，可以及时发现系统中潜在问题并进行处理。

5. Spring Cloud 与服务网关( Zuul )

Spring Cloud 通过集成 Netflix 中的 Zuul 实现 API 服务网关功能，提供对请求的路由和过滤两个功能

路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础。

过滤器功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础。

通过 Zuul ，可以将细粒度的服务组合起来提供一个粗粒度的服务，所有请求都导入一个统一的入口，对外整个服务只需要暴露一个 API 接口，屏蔽了服务端的实现细节。通过 Zuul 的反向代理功能，可以实现路由寻址，将请求转发到后端的粗粒度服务上，并做一些通用的逻辑处理。此外， Zuul 默认会与 Eureka 服务器进行整合，自动从 Eureka 服务器中获取所有注册的服务并进行路由映射，实现 API 服务网关自动配置。

6. Spring Cloud 与消息中间件( Stream )

Spring Cloud 为简化基于消息的开发，提供了 Stream 子项目，通过建立消息应用抽象层，构建了消息收发、分组消费和消息分片等功能处理，将业务应用中的消息收发与具体消息中间件进行解耦，使微服务应用开发中可以非常方便地与 Kafka 和 RabbitMQ 等消息中间件进行集成。

Spring Cloud Bus 基于 Stream 进行扩展，可以作为微服务之间的事件、消息总线，用于服务集群中状态变化的传播。

比如 Spring Cloud Config 借助 Bus ，可以实现配置的动态刷新处理。

7. Spring Cloud 与分布式配置中心( Config )

针对微服务架构下的配置文件管理需求， Spring Cloud 提供了一个 Config 子项目。 Spring Cloud Config 具有中心化、版本控制、支持动态更新和语言独立等特性。

在 Config 子项目中将微服务应用分为两种角色：配置服务器（ Config Server ）和配置客户端（ Config Client ）。使用配置服务器集中地管理所有配置属性文件，配置服务中心可以将配置属性文件存储到 Git 、 SVN 等具有版本管理仓库中，也可以存放在文件系统中。默认采用 Git 的方式进行存储，因此可以很容易地对配置文件进行修改，并实现版本控制。

8. Spring Cloud 与微服务链路追踪( Sleuth )

Spring Cloud 中的 Sleuth 子项目为开发者提供了微服务之间调用的链路追踪。

Sleuth 核心思想就是通过一个全局的 ID 将分布在各微服务服务节点上的请求处理串联起来，还原了调用关系，并借助数据埋点，实现对微服务调用链路上的性能数据的采集。

因此，通过 Sleuth 可以很清楚地了解到一个用户请求经过了哪些服务、每个服务处理花费了多长时间，从而可以对用户的请求进行分析。此外，通过将采集的数据发送给 Zipkin 进行存储、统计和分析，从而可以实现可视化的分析和展示，帮助开发者对微服务实施优化处理。

9. Spring Cloud 与微服务安全( Security )

Spring Cloud Security 为我们提供了一个认证和鉴权的安全框架，实现了资源授权、令牌管理等功能，同时结合 Zuul 可以将认证信息在微服务调用过程中直接传递，简化了我们进行安全管控的开发。

Spring Cloud Security 默认支持 OAuth 2.0 认证协议，因此单点登录也可以非常容易实现，并且 OAuth2.0 所生成的令牌可以使用 JWT 的方式，进一步简化了微服务中的安全管理。

10. Spring Cloud 的其他子项目

㈤ 微服务架构是什么

微服务架构是一项在云中部署应用和服务的新技术。

大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。

微服务架构相关介绍：

微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。

在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。

微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。

如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。

服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。

㈥ 主流微服务框架有哪些

分享13个可靠的Java微服务架构
1、Spring Boot
2、Eclipse MicroProfile
3、Dropwizard
4、WildFly Thorntail
5、Helidon
6、Cricket
7、Jersey
8、Play
9、Swagger
10、Restlet
11、Squash
12、Telepresence
13、Zipkin

㈦ 开源推荐-C++开发的微服务框架Tars

Tars致力于建设微服务技术生态，在底层基础设施、服务框架、上层应用以及DevOps等方面，都做了较为深入的研发。

2020年3月10日，Linux基金会正式宣布旗下的TARS开源项目成立TARS子基金会。这是一个 专注于微服务领域 的开源基金会，致力于帮助企业拥抱微服务体系架构，解决在使用微服务方面可能出现的问题。这是首个 起源于中国开源项目 的国际开源基金会，也是Linux基金会下 唯一聚焦微服务技术生态 的子基金会。

Tars基金会里目前收录了9个项目，分为5部分：工具集（Tars Lab）、服务治理（Service Governance）、微服务开发框架（Development Framwork）、存储（DCache）和基础设施（Infrustructure）。

1、Tars Lab

Tars Lab项目提供了压力测试TarsJMeter，基准测试集TarsBenchmark和一些开发工具包。TarsJavaStart，可以生成服务端和客户端的TarsJava脚手架，快速开始Tars服务的开发。TarsTools，是一款支持多种IDE的JetBrains插件，为实现编辑Jce/Tars文件使用的（支持Intellij IDEA、Android Studio、PhpStorm、WebStorm、GoLand、CLion等）。

2、服务治理

服务治理包含了2个项目：TSeer专注于处理服务注册与发现；TarsGateway是基于Tars框架开发的微服务网关，除具备网关的基础功能外，还可以自动将HTTP转换成Tars-RPC协议。

3、微服务开发框架

这部分只包含Tars一个项目，核心模块由C++开发，提供了多语言开发框架，默认rpc调用，是Tars基金会的核心项目。其他项目都是围绕这个项目研发的。

4、微服务存储

这部分只包含DCache一个项目，它是基于Tars框架开发的 分布式共享内存存储系统 ，支持常用的kv数据结构、支持二级索引、支持在线扩缩容、支持自动持久化到后端db等特性。DCache依赖Tars框架的运行，但也得益于Tars，使得存储服务的运维成本几乎为0。

5、微服务基础设施

这是一个将Tars与K8S融合使用的项目，致力于将Tars融入到K8S生态中。

在这方面还有一个更优秀的项目K8SFramework，致力于将Tars与K8S深度融合，相信未来会纳入到基金会中。

| Tars的前世今生

Tars的前身是腾讯内部的TAF框架，已经经过了10年的验证，稳定运行与1.6w+服务器，100多个业务线中。

据统计， Tars已在超过 120 家公司、 261200 台服务器上稳定运行。

在分布式环境下，所有的微服务（包括DCache的服务）都可以通过框架自带的控制台-TarsWeb进行管理， 可以做到所有服务状态可监控，可以在控制台上进行启停、修改配置、执行运维指令等操作。

在分布式部署的情况下，可以通过Web控制台实现一键升级、回退。

Tars自带配置中心，分级配置，可以统一修改配置，做到“一点修改，全局生效”。

在服务部署时，可以在界面上填写要发布的节点，一键部署、扩容。

框架提供了状态监控的能力，可以监控服务的调用质量，如流量情况，平均耗时、超时率和异常率。

框架状态可以在控制台上一键核查。

Tars提供配套的性能测试工具，这也是Tars基金会的子项目。性能测试工作不再依赖专业的测试人员。

| Tars优势

1、原生RPC调用

Tars使用自研的RPC协议通信，服务之间建立长连接，在通信频繁的场景下具备显着的性能优势。

2、多语言支持

除C++和Java外，Tars还支持NodeJs，PHP，Go等语言，提供了相应的SDK。当团队技术栈多样化时，可以多语言协同开发，无缝对接，开发者可以选择自己熟悉的语言进行开发，提升团队整体效率。

在这方面，Spring Cloud想要支持异构语言，需要借助SideCar构建Service Mesh。 业界现在有一些比较流行的服务网格解决方案，但是 并没有形成统一的标准 ， 可移植性不高 。比较常见的像Istio，由于是代理模式，而且非长连接，会存在 更大的延迟 。另一方面，Istio的部署和运维都非常 复杂 ，需要更多的学习成本和运维成本。

3、内置服务治理功能

Tars框架内嵌了丰富的服务治理功能，包括熔断、限流、负载均衡、认证、加密等。同时，在服务监控、数据采集，以及灰度部署、跨机房部署等方面，都原生支持，集成度高。

Spring Cloud要支持这些功能，要么需要集成其他组件，要么需要设计开发来实现。都需要付出额外的学习成本和研发成本。

4、运维监控

Tars为使用者提供了一体化的运维管理控制台，我们可以在Web上进行一键部署、扩容、升级、回退等运维操作。

Spring Cloud并没有配套的工具。要实现Web管控， 需要借助K8S和容器，同样需要付出额外的成本。

5、国产化

Tars是国内公司主导的开源项目，这一点就不多说什么了。

6、“套装”优势

Tars框架提供了微服务相关的一体化解决方案，常规情况下不需要再去集成其他组件，不存在兼容性问题。这就好比MacBook和兼容机的区别，兼容机你可能需要付出更多的试错成本才能达到想要的效果。

| 劣势

1、项目热度

Tars开源较晚，到目前只有5年多时间，项目热度不如Spring Cloud，应用也没Spring Cloud广泛。

2、Tars的云原生之路

Tars和K8s的深度融合也开源不久（2020年7月，K8SFramework），还有待落地验证。这个项目现在的更新频率较高，不建议在生产中使用。但是从这一点也可以看到社区工作者对Tars与K8S融合的高涨热情，相信未来这个项目一定会大放异彩！

Tars在微服务开发、运维、监控等方面提供了一体化的解决方案，可以帮助我们低成本构建企业级微服务。适用于各种规模的团队，各种规模的系统。

在做技术选型时，如果团队中有C++开发人员，或者有多语言开发的情况，而且团队规模、资源有限的情况下，建议选择Tars。它在运维、监控、测试等方面会为我们节约大量成本。

未来，随着 K8SFramework 项目的日渐成熟，相信Tars生态会被更多的团队熟知和使用。

㈧ 六种常用的微服务架构设计模式（建议收藏）

简单地说，API主导的连接方法可以被看作是API设计的一种分层方法（至少在本文中是这样）。其中，系统API公开系统的资产数据信息；中间的是流程API，与系统API一起进行编排和组合；顶端的体验API公开来自后端数据源的数据，提供最终用户体验。这种API分层方法与细粒度SOA模式很好地结合在一起，通常，这两者要么可以共存，要么细粒度SOA模式演化成基于细粒度SOA的分层API模式。

API主导的连接方法为细粒度SOA模式提供了一些层次结构，这些层次结构允许对API或微服务进行一致的管理和治理。然而，基于细粒度SOA的分层API模式也存在一些与细粒度SOA 模式类似的深层问题（这很直观）：

在细粒度SOA模式执行单个API调用的地方，基于细粒度SOA的分层API模式现在必须通过层执行多个调用。从“网络跳数”的角度来看，这种模式可能是低效的。但是，基于细粒度SOA的分层API模式中，层次结构的存在并不强制跨越网络来调用每个API。直接的跨层调用，而不是通过网络调用是完全有效的；分层的目的是为了增加灵活性，同时以一种很好地分离关注点的方式构建体系架构。

在细粒度SOA模式管理大量服务的地方，使用分层API将会管理来自多个层次的大量细粒度服务。您的管理工具可能不再像以前那样有效，因为它们可能无法可视化复杂的微服务视图。

最终应用程序的数据存储一致性在分层API模式下实际上得到了改善，因为访问数据的服务都是有组织，且集中地查询或修改应用程序的状态。（例如：系统API）

实际上，对于大多数企业来说，基于细粒度SOA的分层API模式是一个很好的模式，但是，就像细粒度SOA模式一样，在实践过程中会出现困难。然而，这种困难通常在大范围使用时才会显现出来。因此，只有在预期或正在经历大规模的使用时，我们才应该准备其他的模式。

问题：

没有一定层次结构的微服务架构是很难进行合理解释的，因为没有明显的方法来对每个微服务的用途进行分类和可视化。

解决方案：

通过创建按用途分组的分层API（系统层、流程及领域模型层，以及体验层），您可以更容易地管理微服务架构的复杂性。

应用：

将微服务架构分为多个层。通常情况下，可以使用标准化，并具有类似用途的一组微服务以类似的方式工作，从而进一步使微服务架构的复杂性合理化。

影响：

1.通过标准化和进一步分解微服务架构，可以提高快速变更的能力。

2.由于更专门化的层次结构，进程间服务调用的数量可能增加。

3.需要对服务监控和可视化工具进行检查，以确定它们是否能够正确地与分层架构一起工作。

目标：

1.快速的敏捷变更。

2.可伸缩性：理论上通过基于细粒度SOA的分层API模式可以提高可伸缩性，但实际上，除非有支持自动化的基础设施，否则可伸缩性往往会降低。

主要特点：

1.为了实现快速变更，可能存在低效的IPC（Inter-Process Communication，进程间通信）。

2.数据一致性和状态管理能力较差，但允许高度重用。重用本身会抵消变更的速度。

3.由于与现存模式的相似性，已有的问题往往同样会出现。

4.基于细粒度SOA的分层API模式在小范围内使用效果很好，在大规模情况下会出现困难。

5.由于采用了结构化的体系架构方法，所以具有很高的内聚性。

6.重点放在服务颗粒度要细，但通常没有考虑其能力。

7.基于细粒度SOA的分层API模式以集成为导向，每个微服务依赖于外部系统。这将会降低变更的速度。

基于细粒度SOA的分层API模式如何与SOA或API等现有系统共存？

基于细粒度SOA的分层API模式往往是与现有IT资产共存的最佳方式。由于分层减少了每个微服务的范围，并约束了其用途，因此该模式能够在不明显降低变更速度的情况下，最好地连接和利用现有IT系统。然而，通过细粒度和分层的设计来协调变更可能是一个挑战。您可能需要使用一定的技术手段来管理所有不同微服务之间的契约，或者使用完全自动化的测试技术来确保变更不会造成破坏。

㈨ 目前比较流程的微服务开发框架是

1、首先你的问题应该写错了，应该是目前比较流行的微服务开发框架，而不是比较流程的微服务开发框架。

2、目前比较流行的微服务框架是springBoot，Spring Boot是JAVA平台的微服务框架，是由Pivotal团队提供的全新框架，其设计目的是用来简化新Spring应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。通过这种方式，Spring Boot致力于在蓬勃发展的快速应用开发领域(rapid application development)成为领导者。

㈩ 微服务架构：基于微服务和Docker容器技术的PaaS云平台架构设计

基于微服务架构和Docker容器技术的PaaS云平台建设目标是给我们的开发人员提供一套服务快速开发、部署、运维管理、持续开发持续集成的流程。平台提供基础设施、中间件、数据服务、云服务器等资源，开发人员只需要开发业务代码并提交到平台代码库，做一些必要的配置，系统会自动构建、部署，实现应用的敏捷开发、快速迭代。在系统架构上，PaaS云平台主要分为微服务架构、Docker容器技术、DveOps三部分，这篇文章重点介绍微服务架构的实施。

如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。

实施微服务需要投入大量的技术力量来开发基础设施，这对很多公司来说显然是不现实的，别担心，业界已经有非常优秀的开源框架供我们参考使用。目前业界比较成熟的微服务框架有Netflix、Spring Cloud和阿里的Dubbo等。Spring Cloud是基于Spring Boot的一整套实现微服务的框架，它提供了开发微服务所需的组件，跟Spring Boot一起使用的话开发微服务架构的云服务会变的很方便。Spring Cloud包含很多子框架，其中Spring Cloud Netflix是其中的一套框架，在我们的微服务架构设计中，就使用了很多Spring Cloud Netflix框架的组件。Spring Cloud Netflix项目的时间还不长，相关的文档资料很少，博主当时研究这套框架啃了很多英文文档，简直痛苦不堪。对于刚开始接触这套框架的同学，要搭建一套微服务应用架构，可能会不知道如何下手，接下来介绍我们的微服务架构搭建过程以及 需要那些 框架或组件来支持微服务架构。

为了直接明了的展示微服务架构的组成及原理，画了一张系统架构图，如下：

从上图可以看出，微服务访问大致路径为：外部请求 → 负载均衡 → 服务网关（GateWay）→ 微服务 → 数据服务/消息服务。服务网关和微服务都会用到服务注册和发现来调用依赖的其他服务，各服务集群都能通过配置中心服务来获得配置信息。

服务网关（GateWay）

网关是外界系统（如：客户端浏览器、移动设备等）和企业内部系统之间的一道门，所有的客户端请求通过网关访问后台服务。为了应对高并发访问，服务网关以集群形式部署，这就意味着需要做负载均衡，我们采用了亚马逊EC2作为虚拟云服务器，采用ELB(Elastic Load Balancing)做负载均衡。EC2具有自动配置容量功能，当用户流量达到尖峰，EC2可以自动增加更多的容量以维持虚拟主机的性能。ELB弹性负载均衡，在多个实例间自动分配应用的传入流量。为了保证安全性，客户端请求需要使用https加密保护，这就需要我们进行SSL卸载,使用Nginx对加密请求进行卸载处理。外部请求经过ELB负载均衡后路由到GateWay集群中的某个GateWay服务，由GateWay服务转发到微服务。服务网关作为内部系统的边界，它有以下基本能力：

1、动态路由：动态的将请求路由到所需要的后端服务集群。虽然内部是复杂的分布式微服务网状结构，但是外部系统从网关看就像是一个整体服务，网关屏蔽了后端服务的复杂性。

2、限流和容错：为每种类型的请求分配容量，当请求数量超过阀值时抛掉外部请求，限制流量，保护后台服务不被大流量冲垮；党内部服务出现故障时直接在边界创建一些响应，集中做容错处理，而不是将请求转发到内部集群，保证用户良好的体验。

3、身份认证和安全性控制：对每个外部请求进行用户认证，拒绝没有通过认证的请求，还能通过访问模式分析，实现反爬虫功能。

4、监控：网关可以收集有意义的数据和统计，为后台服务优化提供数据支持。

5、访问日志：网关可以收集访问日志信息，比如访问的是哪个服务？处理过程（出现什么异常）和结果？花费多少时间？通过分析日志内容，对后台系统做进一步优化。

我们采用Spring Cloud Netflix框架的开源组件Zuul来实现网关服务。Zuul使用一系列不同类型的过滤器（Filter），通过重写过滤器，使我们能够灵活的实现网关（GateWay）的各种功能。

如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。

服务注册与发现

由于微服务架构是由一系列职责单一的细粒度服务构成的网状结构，服务之间通过轻量机制进行通信，这就引入了服务注册与发现的问题，服务的提供方要注册报告服务地址，服务调用放要能发现目标服务。我们的微服务架构中使用了Eureka组件来实现服务的注册与发现。所有的微服务（通过配置Eureka服务信息）到Eureka服务器中进行注册，并定时发送心跳进行 健康 检查，Eureka默认配置是30秒发送一次心跳，表明服务仍然处于存活状态，发送心跳的时间间隔可以通过Eureka的配置参数自行配置，Eureka服务器在接收到服务实例的最后一次心跳后，需要等待90秒（默认配置90秒，可以通过配置参数进行修改）后，才认定服务已经死亡（即连续3次没有接收到心跳），在Eureka自我保护模式关闭的情况下会清除该服务的注册信息。所谓的自我保护模式是指，出现网络分区、Eureka在短时间内丢失过多的服务时，会进入自我保护模式，即一个服务长时间没有发送心跳，Eureka也不会将其删除。自我保护模式默认为开启，可以通过配置参数将其设置为关闭状态。

Eureka服务以集群的方式部署（在博主的另一篇文章中详细介绍了Eureka集群的部署方式），集群内的所有Eureka节点会定时自动同步微服务的注册信息，这样就能保证所有的Eureka服务注册信息保持一致。那么在Eureka集群里，Eureka节点是如何发现其他节点的呢？我们通过DNS服务器来建立所有Eureka节点的关联，在部署Eureka集群之外还需要搭建DNS服务器。

当网关服务转发外部请求或者是后台微服务之间相互调用时，会去Eureka服务器上查找目标服务的注册信息，发现目标服务并进行调用，这样就形成了服务注册与发现的整个流程。Eureka的配置参数数量很多，多达上百个，博主会在另外的文章里详细说明。

微服务部署

微服务是一系列职责单一、细粒度的服务，是将我们的业务进行拆分为独立的服务单元，伸缩性好，耦合度低，不同的微服务可以用不同的语言开发，每一个服务处理的单一的业务。微服务可以划分为前端服务（也叫边缘服务）和后端服务（也叫中间服务），前端服务是对后端服务做必要的聚合和剪裁后暴露给外部不同的设备（PC、Phone等），所有的服务启动时都会到Eureka服务器进行注册，服务之间会有错综复杂的依赖关系。当网关服务转发外部请求调用前端服务时，通过查询服务注册表就可以发现目标服务进行调用，前端服务调用后端服务时也是同样的道理，一次请求可能涉及到多个服务之间的相互调用。由于每个微服务都是以集群的形式部署，服务之间相互调用的时候需要做负载均衡，因此每个服务中都有一个LB组件用来实现负载均衡。

微服务以镜像的形式，运行在Docker容器中。Docker容器技术让我们的服务部署变得简单、高效。传统的部署方式，需要在每台服务器上安装运行环境，如果我们的服务器数量庞大，在每台服务器上安装运行环境将是一项无比繁重的工作，一旦运行环境发生改变，就不得不重新安装，这简直是灾难性的。而使用Docker容器技术，我们只需要将所需的基础镜像（jdk等）和微服务生成一个新的镜像，将这个最终的镜像部署在Docker容器中运行，这种方式简单、高效，能够快速部署服务。每个Docker容器中可以运行多个微服务，Docker容器以集群的方式部署，使用Docker Swarm对这些容器进行管理。我们创建一个镜像仓库用来存放所有的基础镜像以及生成的最终交付镜像，在镜像仓库中对所有镜像进行管理。

服务容错

微服务之间存在错综复杂的依赖关系，一次请求可能会依赖多个后端服务，在实际生产中这些服务可能会产生故障或者延迟，在一个高流量的系统中，一旦某个服务产生延迟，可能会在短时间内耗尽系统资源，将整个系统拖垮，因此一个服务如果不能对其故障进行隔离和容错，这本身就是灾难性的。我们的微服务架构中使用了Hystrix组件来进行容错处理。Hystrix是Netflix的一款开源组件，它通过熔断模式、隔离模式、回退（fallback）和限流等机制对服务进行弹性容错保护，保证系统的稳定性。

1、熔断模式：熔断模式原理类似于电路熔断器，当电路发生短路时，熔断器熔断，保护电路避免遭受灾难性损失。当服务异常或者大量延时，满足熔断条件时服务调用方会主动启动熔断，执行fallback逻辑直接返回，不会继续调用服务进一步拖垮系统。熔断器默认配置服务调用错误率阀值为50%，超过阀值将自动启动熔断模式。服务隔离一段时间以后，熔断器会进入半熔断状态，即允许少量请求进行尝试，如果仍然调用失败，则回到熔断状态，如果调用成功，则关闭熔断模式。

2、隔离模式：Hystrix默认采用线程隔离，不同的服务使用不同的线程池，彼此之间不受影响，当一个服务出现故障耗尽它的线程池资源，其他的服务正常运行不受影响，达到隔离的效果。例如我们通过andThreadPoolKey配置某个服务使用命名为TestThreadPool的线程池，实现与其他命名的线程池隔离。

3、回退（fallback）：fallback机制其实是一种服务故障时的容错方式，原理类似Java中的异常处理。只需要继承HystixCommand并重写getFallBack()方法，在此方法中编写处理逻辑，比如可以直接抛异常（快速失败），可以返回空值或缺省值，也可以返回备份数据等。当服务调用出现异常时，会转向执行getFallBack()。有以下几种情况会触发fallback：

1）程序抛出非HystrixBadRequestExcepption异常，当抛出HystrixBadRequestExcepption异常时，调用程序可以捕获异常，没有触发fallback，当抛出其他异常时，会触发fallback；

2）程序运行超时；

3）熔断启动；

4）线程池已满。

4、限流： 限流是指对服务的并发访问量进行限制，设置单位时间内的并发数，超出限制的请求拒绝并fallback，防止后台服务被冲垮。

Hystix使用命令模式HystrixCommand包装依赖调用逻辑，这样相关的调用就自动处于Hystrix的弹性容错保护之下。调用程序需要继承HystrixCommand并将调用逻辑写在run()中，使用execute()（同步阻塞）或queue()（异步非阻塞）来触发执行run()。

动态配置中心

微服务有很多依赖配置，某些配置参数在服务运行期间可能还要动态修改，比如：根据访问流量动态调整熔断阀值。传统的实现信息配置的方法，比如放在xml、yml等配置文件中，和应用一起打包，每次修改都要重新提交代码、打包构建、生成新的镜像、重新启动服务，效率太低，这样显然是不合理的，因此我们需要搭建一个动态配置中心服务支持微服务动态配置。我们使用Spring Cloud的configserver服务帮我们实现动态配置中心的搭建。我们开发的微服务代码都存放在git服务器私有仓库里面，所有需要动态配置的配置文件存放在git服务器下的configserver（配置中心，也是一个微服务）服务中，部署到Docker容器中的微服务从git服务器动态读取配置文件的信息。当本地git仓库修改代码后push到git服务器仓库，git服务端hooks(post-receive，在服务端完成代码更新后会自动调用)自动检测是否有配置文件更新，如果有，git服务端通过消息队列给配置中心（configserver，一个部署在容器中的微服务）发消息，通知配置中心刷新对应的配置文件。这样微服务就能获取到最新的配置文件信息，实现动态配置。

以上这些框架或组件是支撑实施微服务架构的核心，在实际生产中，我们还会用到很多其他的组件，比如日志服务组件、消息服务组件等等，根据业务需要自行选择使用。在我们的微服务架构实施案例中，参考使用了很多Spring Cloud Netflix框架的开源组件，主要包括Zuul（服务网关）、Eureka（服务注册与发现）、Hystrix（服务容错）、Ribbon（客户端负载均衡）等。这些优秀的开源组件，为我们实施微服务架构提供了捷径。

如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。