1.什么是微服务架构
简单来说微服务是系统架构上的一种设计风格，他的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RESTful API进行通信协作。而且被拆成的每一项小型的服务都围绕着系统中的某一项或某一些耦合度较高的业务功能进行构建，并且每个服务都维护着自身的数据存储。
2.产生原因
为了解决单体系统变大庞大臃肿之后产生的难以维护的问题，所以微服务架构诞生了并被大家所关注。
3.如何实施微服务
- 1.运维的新挑战
在微服务架构中，运维人员需要维护的进程数量会大大增加。有条不紊的将这些进程编排和组织起来并不是一件容易的事，传统的运维人员往往很难适应这样的改变。- 2.接口的一致性
虽然我们拆分了业务，但是从逻辑上的依赖并不会消除，只是从单体应用中的代码依赖变为服务之间的通信依赖。而当我们对原有接口进行了一些修改，那么交互方也需要协调这样的方式进行发布。- 3.分布式的复杂性
由于拆分之后的各个微服务都是独立部署并运行在各自的进程内，他们只能通过通信来进行协作，所以分布式环境的问题都将会是微服务架构系统设计时需要考虑的重要因素，比如网络延迟，分布式事务，异步消息等。
虽然微服务架构有很多的缺点和问题，但是其实现了敏捷开发和自动化部署等优点。
4.微服务的九大特性
由于面对环境、资源、团队等各种因素的影响，几乎不会出现完全相同的架构设计。对于微服务架构而言更是如此，但是针对这些挑战，有九大特性可以指导大家设计架构
4.1 服务组件化
组件是一个可以独立更换和升级的单元。就想PC中的cpu、内存、显卡、硬盘一样，独立而且可以更换升级并且不影响其他单元。
在微服务架构中，需要我们对服务进行组件化分解。服务，是一种进程外的组件，他通过Http等通信协议进行协作，而不是像传统组件那样以嵌入式的方式进行协同工作。每一个服务都独立开发部署，可以有效的避免一个服务的修改引起整个系统的重新部署。
4.2 按业务组织团队
当决定如何划分服务时，通常也意味着我们要开始对团队进行重新规划和组织。按照传统的划分方式，我们一般会按照技术进行划分，比如DBA团队（数据库的日常维护工作），运维团队，前后端开发团队，设计师团队等，若我们继续沿用这种方式组织团队来开发微服务，当一个服务发生变动时，可能是一个及其细微的变动，比如对人物的描述增加一个字段，这需要从数据存储开始考虑一直到设计和前端。
在实施微服务架构时，需要采用不同的团队分割方法，由于每一个微服务都是针对特定的业务的宽栈或是全栈，既要负责数据的持久化存储，又要负责用户接口的定义等各种跨专业领域的职能，因此，面对大型项目的时候，对于微服务团队的拆分更加建议按业务线拆分，一方面可以减少服务内部修改所产生的内耗；另一方面，团队边界可以做的更加清晰。
4.3 做“产品的态度
在实施微服务架构的团队中，每一个小团队都应该以做产品的方式，对其产品的整个生命周期负责。而不是以项目的模式，以完成开发与交付并将成果交接给维护者为最终目标；
4.4 智能端点与哑管道
在单体应用中，组件之间直接通过函数调用的方式进行协作。而在微服务架构中，由于服务不在一个进程中，组件之间的通信模式会发生改变，若仅仅将原本进程内的方法调用改成RPC方式调用，会导致服务之间产生繁琐的通信，使得系统表现的更为糟糕，所以我们需要更粗粒度的通信协议。
在微服务架构中，通常会使用以下两种服务调用方式：
- 1.使用Http的RESTful API 或轻量级的消息发送协议，实现消息传递与服务调用的触发
- 2.通过在轻量级消息总线上传递消息，类似RabbitMQ等提供一些可靠的异步交换中间件。
4.5 去中心化治理
在实施微服务架构时，通过采用轻量级的契约定义接口，使得我们对于服务本身的具体技术平台不再那么敏感，这样整个微服务系统中的各个组件就能针对其不同的业务特点选择不同的技术平台。
4.6 去中心化管理数据
让每一个服务来管理自有的数据库这就是数据管理的去中心化。
我们可以将一些具有特殊结构的或者业务特性的数据存储到其他数据库平台中，比如将日志信息存储到mogoDB中或者把用户登录信息存储到redis中、
由于数据存储于不同的数据库实例中后，数据的一致性也成为微服务架构中亟待解决的问题之一。分布式事务本身难度就非常大，所以在微服务的各个服务之间进行“无事务”的调用非常有必要，对于数据的一致性，只要求数据在最后的处理状态一直即可；若在过程中发现错误，通过补偿机制来进行处理，使得错误能够达到最终的一致性。
4.7 基础设施自动化
近年来云计算服务与容器化技术的不断成熟，运维基础设施的工作变得越来越容易。但是，当我们实施微服务架构时，数据库、应用程序的个头虽然都变小了，但是因为拆分的原因，数量成倍增长。这使得运维人员需要关注的内容也成倍增长，并且操作性任务也会成倍增长，这些问题若没有得到妥善解决，必将成为运维人员的噩梦。所以，在微服务架构中，务必从一开始就构建起“持续交付”平台来支撑整个实施过程，该平台需要两大内容，缺一不可。
- 自动化测试:每次部署前的强心剂，尽可能地获得对正在运行的软件的信心。
- 自动化部署:解放烦琐枯燥的重复操作以及对多环境的配置管理。
4.8 容错设计
在单体应用中，一般不存在单个组件故障而其他部件还在运行的情况，通常是一挂全挂。而在微服务架构中，由于服务都运行在独立的进程中，所以存在部分服务出现故障，而其他服务正常运行的情况。比如，当正常运作的服务B调用到故障服务A时，因故障服务A没有返回，线程挂起开始等待，直到超时才能释放，而此时若触发服务B调用服务A的请求来自服务C，而服务C频繁调用服务B时，由于其依赖服务A，大量线程被挂起等待，最后导致服务A也不能正常服务，这时就会出现故障的蔓延。
所以，在微服务架构中，快速检测出故障源并尽可能地自动恢复服务是必须被设计和考虑的。通常，我们都希望在每个服务中实现监控和日志记录的组件，比如服务状态、断路器状态、吞吐量、网络延迟等关键数据的仪表盘等。
4.9 演进式设计
要实施一个完美的微服务架构，需要考虑的设计与成本并不小，对于没有足够经验的团队来说，甚至要比单体应用付出更多的代价。
所以，在很多情况下，架构师都会以演进的方式进行系统的构建。
在初期，以单体系统的方式来设计和实施，一方面系统体量初期并不会很大，构建和维护成本都不高。另一方面，初期的核心业务在后期通常也不会发生巨大的改变。
随着系统的发展或者业务的需要，架构师会将一些经常变动或是有一定时间效应的内容进行微服务处理，并逐渐将原来在单体系统中多变的模块逐步拆分出来，而稳定不太变化的模块就形成一个核心微服务存在于整个架构之中。
5.SpringCloud简介
Spring Cloud是一个基于Spring Boot实现的微服务架构开发工具。它为微服务架构中涉及的配置管理、服务治理、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。
Spring Cloud包含了多个子项目(针对分布式系统中涉及的多个不同开源产品，还可能会新增)，如下所述。
- Spring Cloud Config:配置管理工具，支持使用Git存储配置内容，可以使用它实现应用配置的外部化存储，并支持客户端配置信息刷新、加密/解密配置内容等。
- Spring Cloud Netflix:核心组件，对多个Netflix OSS开源套件进行整合。
- Eureka:服务治理组件，包含服务注册中心、服务注册与发现机制的实现。
- Hystrix:容错管理组件，实现断路器模式，帮助服务依赖中出现的延迟和为故障提供强大的容错能力。
- Ribbon:客户端负载均衡的服务调用组件。
- Feign:基于Ribbon和 Hystrix的声明式服务调用组件。
- Zuul:网关组件，提供智能路由、访问过滤等功能。
- Archaius:外部化配置组件。
- Spring Cloud Bus:事件、消息总线，用于传播集群中的状态变化或事件，以触发后续的处理，比如用来动态刷新配置等。
- Spring Cloud Cluster:针对ZooKeeper、Riedis、Hazelcast、Consul的选举算法和通用状态模式的实现。
- Spring Cloud Cloudfoundry:与Pivotal Cloudfoundry的整合支持。Spring Cloud Consul:服务发现与配置管理工具。
- Spring Cloud Stream:通过Redis、Rabbit或者Kafka实现的消费微服务，可以通过简单的声明式模型来发送和接收消息。
- Spring Cloud AWS:用于简化整合Amazon Web Service的组件。
- Spring Cloud Security:安全工具包，提供在Zuul代理中对OAuth2客户端请求的中继器。
- Spring Cloud Sleuth: Spring Cloud应用的分布式跟踪实现，可以完美整合Zipkin。Spring Cloud ZooKeeper:基于ZooKeeper 的服务发现与配置管理组件。
- Spring Cloud Starters: Spring Cloud的基础组件，它是基于Spring Boot风格项目的基础依赖模块。
- Spring Cloud CLI:用于在Groovy中快速创建Spring Cloud应用的Spring Boot CLI插件。
下一篇：SpringCloud02—微服务构建：SpringBoot
78万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
