大话微服务：（三）微服务架构与中台战略

一、前言

      随着移动互联网规模的不断扩大，敏捷开发，持续交付，DevOps理论的发展和实践，以及容器技术的成熟，微服务架构开始流行。

二、微服务的核心：

微服务的核心在于服务治理，微服务架构是将复杂臃肿的单体应用进行细粒度的服务化拆分，每个拆分出来的服务各自独立打包部署，并交由小团队进行开发和运维，从而极大地提高了应用交付的效率。

三、中台战略

 

四、微服务开发技术spring boot

 

五、微服务架技术架构spring cloud

spring cloud就是微服务的大管家（大哥），维护微服务的生态，微服务的治理（即专注于服务之间的通讯、熔断、监控等），它的核心组件（小弟们）：

（一）对微服务治理需求：

      1.开发完的微服务放哪儿，各个微服务之间如何调用（即互相能自动找到）？

       2.各个微服务如何调用（外网如何调用即http？内网如何调用即RPC）？

       3.微服务的作业如何保障？

          3.1.如何保证各个微服务正常工作？出错了怎么办？

          3.2.并发性太大时，单个微服务满足不了时，一样的微服务集群的方式部署N台服务器上，他们如何智能去调用空闲的，性能好的微服务所在机器？如果并发数超过了响应，怎么办是等候，还是服务降级调用本地服务(例如提醒等）？

         3.3.微服务之间由于网址不一样，跨域如何解决？服务安全如何保证？

 

（二）满足微服务治理的技术方案Spring Cloud Netflix 简单介绍：

核心：Eurka（译音尤里卡） ：服务注册中心，它们的工作模式是将所有的微服务注册到一个 Server 上，然后通过心跳进行服务健康监测。这样服务 A 调用 B 时可以从注册中心拿到可用的服务 B 的地址、端口进行调用。服务注册中心也可以多台服务器电脑。

核心：Ribbon：消费服务，客户端负载均衡（它的消费者为PRC远程调用，即Ribbon + Rest，和Feign)

Feign：声明式的伪http客户端(即区别于Rest调用），本质上Ribbo+Hystrix，它集成了Ribbo，默认实现了负载均衡。

           特征：基于接口的注解来调用微服务，象本地方法一样调用。

Hystrix：本质优化Ribbon，关于服务雪崩的解决方案--服务熔断、服务降级、隔离资源。

Zuul：Api服务路由网关（解决跨域问题，过滤问题）

三、总结：

  微服务注册中心：服务提供，服务注册

  微服务消费：http rest和Feign 两者调用消费模式

  微服务生命周期保障：

       A.服务雪崩与断路器：服务故障的处理策略，同时监控哪些服务出故障了。

       B.服务的暴露和路由网关：服务安全考虑不直接暴露，路由网关这个小弟负责转发和过滤。对应到 Spring Cloud 中有 Zuul 和 Gateway 两个组件可用，路由网关接收了所有的用户请求，有着很高的负载，因此它通常是一个集群。用户的请求会先经过一层负载均衡被发到路由网关。

       C.服务配置与配置中心:  在微服务应用中，服务数量巨多，而每个服务不同环境都有着不同的配置，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。需要注意的是此处的配置与注册中心注册的配置信息是两个概念，此处的配置是服务本身的一些配置信息,Spring Cloud 提供了 Spring Cloud Config 组件，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程 Git 仓库中，帮助我们管理服务的配置信息。

      D.信息同步与消息总线:  前一个问题讲到了每个服务都有一些配置信息，那么配置信息更新了我们该怎么办，手动一个个去更新？当然不是，Spring Cloud 提供了 Spring Cloud Bus 组件，它通过轻量消息代理连接各个分布的节点。当配置信息更新的时候，我们只要更新一个节点的配置，这个更新就会被广播到这个分布式系统中。

      E. 问题定位与链路追踪:  在微服务系统中，服务之间可以相互调用，因此我们一个请求可能会一条调用链，而整个系统会存在一张调用网，其中任意一个服务调用失败或网络超时都可能导致整个请求失败。因为调用关系的复杂，这给问题的定位造成了极大的困难，这也是必须提供服务链路追踪的原因。

（三）满足微服务治理的技术方案Spring Cloud Alibaba 简单介绍：