我眼中的微服务以及对Spring Cloud的初步认识

        没有接触过spring cloud的朋友一定对他还不是很熟悉，现在我花小篇幅介绍下spring cloud，Spring cloud是实现微服务架构的一个框架，那么什么是微服务呐？

        微服务是一种项目架构方式

        从宏观意义上来讲，所谓微服务是把单体系统（如下图）的多个模块拆分开来。

        使每一个模块都是一个独立子系统（如下图），也可以说是独立的进程。每个微服务都可以单独部署，各个微服务间是松耦合的。每个服务只关注一件任务并很好的完成该任务。其实微服务不是什么新技术，只是随着业务的不断发展，对业务不断分层、不断拆分形成的一种架构风格。

   微服务的优点

1. 对于学习springcloud这个框架来说我还是很幸运的，因为之前工作中接触过SOA的这个概念，对于我学习springcloud提供了知道思想。

2. 那么微服务和SOA到底有什么关系那，其实SOA是一种面向服务的架构理念，它的主要特性--面向服务的分布式计算，服务间松散耦合，支持服务的封装，服务注册和自动发现，以服务契约方式定义服务交互方式。

3. 目前有两套SOA理念的实现方式：中心化（ESB）和去中心化（微服务架构），这两套架构并没有优劣之分，还是要针对企业的根本诉求。

4. SOA中心化的实现方式也就是ESB，ESB的根本诉求是为了解决异构系统之间的连通性，通过协议转换、消息解析、消息路由把服务提供者的数据传送到服务消费者。所以，ESB是中心化的，很重，有一定的逻辑，但它的确可以解决一些公用逻辑的问题。如果企业中现有多个业务系统、系统间调用依赖关系复杂，系统间数据不能共享、数据孤岛成为各业务系统数据常态，基于现有系统的改造项目我就建议选择ESB的这种方式了。之前工作中做过好几个大的生产型企业的数据中心和门户都是通过这种方式进行的。

5. SOA去中心化的实现方式的根本诉求是扩展性，实现方式就是微服务。分布式服务框架，主要有dubbo、spring cloud，实现后端服务治理的功能。

   微服务与SOA

1. 复杂度可控：微服务在一定程度上解决了复杂性的问题。它会将一种怪异的单体应用程序分解成一组服务。虽然功能总量不变，但应用程序已分解为可管理的块或服务。每个服务都以RPC或消息驱动的API的形式定义了一个明确的边界，将业务的整体复杂度进行了分解。

   独立按需扩展：这种架构使每个服务都能够由专注于该服务的团队独立开发，开发人员可以*选择任何有用的技术，只要该服务符合API规约。

   技术选型灵活：这种*意味着开发人员不再有义务使用在新项目开始时存在的可能过时的技术。在编写新服务时，他们可以选择使用当前的技术。此外，由于服务相对较小，因此使用当前技术重写旧服务变得可行。

   可用性高：微服务架构模式使得每个服务独立扩展。可以根据每个服务的规模来部署满足需求的规模。甚至于，你可以使用更适合于服务资源需求的硬件。甚至允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。

   微服务的缺点

   代码重复：某些底层功能需要被多个服务所用，为了避免将“同步耦合引入到系统中”，有时需要向不同服务添加一些代码，这就会导致代码重复。

   事务控制：一个操作可能涉及多个服务调用，跨越多个独立数据库，事务的实现更具挑战性。

   分布式系统的复杂性：作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题。

   异步机制：微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理以及数据一致性问题，其实现机制会变得复杂化。

   运维难度：微服务将一种怪异的整体应用程序分解成一组服务，可能需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境，以及服务之间可能存在依赖性，会提高运维难度。

   可测性的挑战：在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。经典微服务往往不太重视测试，更多的是通过监控发现生产环境的异常，进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。

   监控：对日志及性能的监控需要顾及多个服务器，实现方案更为复杂。

   微服务架构面临的问题及解决

           当项目新研或者进行服务化改造的时候，这个过程并不是一蹴而就，一拍脑袋就成功了。要把项目服务化，需要解决很多的问题，例如：

   服务之间怎么调用？A服务想要调用到B服务的数据，怎么调用？怎么调用更加的稳定，更加高效？【服务调用技术】

   服务之间怎么负载均衡？A服务要调用B服务，B服务可能有很多个，怎么负载均衡【负载均衡技术】

   服务怎么被管理？服务怎么定位？有故障了怎么处理？【服务注册与发现技术】

   故障怎么监控？微服务系统中业务模块很多，组件也很多，不同组件的指标不同，那么这些组件怎么进行监控【监控技术】

   故障怎么定位？微服务架构中，一个用户的请求会涉及到多个内部服务的调用，那么如何定位问题呢？【链路追踪技术】

   日志怎么分析处理？业务模块多了，日志也就多了，直接查看日志文件已经变的不显示了，那么如何对日志进行分析查找呢？【日志分析技术】

   权限管理？微服务拆分服务之后，会有很多服务对外暴露接口，这些接口如何进行统一的权限处理呢？【网关技术】

   服务调用出现问题怎么处理？当一个服务因为各种原因停止响应时，调用方通常会等待一段时间，然后超时或者收到错误返回。如果调用链路比较长，可能会导致请求堆积，整条链路占用大量资源一直在等待下游响应。怎么解决呢？【熔断，降级，限流】

   还有测试，自动化部署等等问题，都随着微服务的出现到来了，上面的每个问题要进行解决都需要在项目中引入一个或者多个新技术，而这些新技术我们一般称之为组件，也是微服务学习的重点，一整套技术，一套解决上述所有问题的解决方案。

   开始前的准备

          采用微服务架构，边界和职责明确了，模块高内聚低耦合，系统的各模块可用性提高了，而且系统分拆之后，对于负责单个微服务的小团队来说，工作也变得很简单多了。这都是单体架构所不能的。

   在合适的项目，合适的团队，采用微服务架构收益会大于成本。

   然而有个词叫做“架构腐化”，系统不可能静止不动，随着业务的成长，市场的变化，系统总要不断增加新的能力，时间长了，最初简单高效的架构，往往就会变得极其复杂，臃肿不堪，即便最初的规范、分层都合理了，可扩展性、可用性、性能带来的复杂性也是难以避免的。

   明白了这一切，在是否选择微服务架构，或者思考把微服务架构做到什么程度时，必须要看清楚微服务是否能解决自己的问题，同时能否消化掉其衍生出的挑战。 得思考是否有强大的运维力量，是否能驾驭分布式系统的复杂性。在做服务划分时也应根据自己业务情况而定，因为服务划分没有统一的标准，而划分微服务并不是越微越好，谨记微服务是为我们提供便利，而不是给自己挖坑的。

    

   引出spring cloud

          前面分析到使用微服务架构体系时我们又需要多考虑许多问题，不用愁spring cloud都为我们提供的解决方案。

   我所理解的 Spring Cloud 就是微服务系统架构的一站式解决方案，在平时我们构建微服务的过程中需要考虑的上述问题Spring Cloud 为我们提供了一套简易的编程模型，使我们能在 Spring Boot 的基础上轻松地实现微服务项目的构建。

   Spring Cloud 的版本

          当然这个只是个题外话。

          Spring Cloud 的版本号并不是我们通常见的数字版本号，而是一些很奇怪的单词。这些单词均为英国伦敦地铁站的站名。同时根据字母表的顺序来对应版本时间顺序，比如：最早 的 Release 版本 Angel，第二个 Release 版本 Brixton（英国地名），然后是 Camden、 Dalston、Edgware、Finchley、Greenwich、Hoxton。

   Spring Cloud 模块介绍

   Spring Cloud 模块的相关介绍如下：

   Eureka：服务注册中心，用于服务管理。

   Ribbon：基于客户端的负载均衡组件。

   Hystrix：容错框架，能够防止服务的雪崩效应。

   Feign：Web 服务客户端，能够简化 HTTP 接口的调用。

   Zuul：API 网关，提供路由转发、请求过滤等功能。

   Config：分布式配置管理。

   Sleuth：服务跟踪。

   Stream：构建消息驱动的微服务应用程序的框架。

   Bus：消息代理的集群消息总线。

   除了这些模块spring还有cli、task等等。

   Spring cloud是一个很好的框架的集合，它整合了非常多的功能模块，我们文章里不可能一一介绍，我们讲到的都是实际开发当中需要的模块。

         查看原文链接：http://www.sucai66.com/article/detail/20200617/19.html