微服务架构基本概念

1.背景：

随着云计算、开源、Docker等为技术界带来革命性的影响，同时，用户使用方式与生活方式都在移动化浪潮的裹挟下发生了巨变；互联网产品需求来的快，变得快，使得我们的产品需要不断的持续创新，不断给用户带来价值；用户的期望交付周期极大缩短了 ，我们需要以更快的方式迭代并持续集成产品，这就要求我们抛弃传统单体应用，以新的开发，架构，运维方式来解决我们的问题，“微服务”架构（MSA：Micro Service Architecture）这一全新的企业架构模式越来越受到关注，也有越来越多的企业和平台服务商开始将“微服务”的概念转化为实践，掌握到第一手的实战经验。

2.微服务基本概念：

2.1 ）微服务是什么？

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调，配合为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通(通常基于HTTP的RESTFUL API)；每个服务都围绕具体业务进行构建，并且能够被独立地部署到生产环境，类生产环境等，另外应尽量避免统一的，集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言，工具对其构建。

2.2）单块架构的优缺点:

我们所部署的程序是一个功能集中的，代码和数据中心化，一个发布包，部署后运行在同一进程的应用程序。

2.2.1.单块架构优势：

易于开发；

易于测试；

易于部署；

易于水平伸缩：即新建一个服务节点，配置好该节点的运行环境，复制软件包到相应的位置，运行该应用程序；

2.2.2单块架构的挑战：

维护成本增加：随着应用的功能越来越多，沟通，管理，协调，运维等等成本会逐渐增加；

持续交付周期变长：应用功能的不断增加，代码的复杂度上升，构建和部署的周期也将变得越来越长，任何小的改动都将触发部署流水线，如代码编译，单元测试，代码检查，构建生成部署包，验证功能等；

新人培养周期长：对于团队新成员，了解应用程序业务，配置本地环境将需要比以往更多的时间；

技术选型成本高：单块架构采用的是统一的技术平台或方案来解决所有问题，如果尝试引入新的框架，技术或者对现有技术栈升级，通常会面临不小的风险；

可扩展性差：垂直上单台服务器性能有限，如果应用程序功能不断增加，需要性能更高的服务器来部署，但是往往这样成本非常高昂；水平上对于集群的部署，添加的新节点并不能发挥出集群的优势，有些功能可能是CPU密集，有些可能内存密集，往往还得为此加大服务器性能；

2.3）与SOA(Service oriented architecture)对比：

面向服务的体系结构，将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

2.3.1. SOA基本特征：

企业级，自顶向下开展实施；

服务由多个子系统组成，粒度大；

企业服务总线，集中式的服务架构；

集成方式复杂(ESB/WS/SOAP)；

单块架构，相互依赖，部署复杂；

2.3.2.微服务基本特征：

团队级，自底向上开展实施；

一个系统被拆成多个服务，粒度细；

无集中式总线，松散的服务架构；

集成方式简单(HTTP/REST/JSON)；

服务能独立部署；

2.3.3总结：

比传统的SOA服务实现方式，微服务更具灵活性，可实施性以及扩展性其强调的是一种独立测试，部署，运行的软件架构模式。

对于微服务概念而言，它是SOA定义的一个子集；而对于实现方式而言，是更符合现代化发展趋势的实践。

2.4）微服务架构原则：

2.4.1.基本原则:

单一职责：高内聚，低耦合；

轻量级通信：与语言无关；

独立：在应用的交付过程中，开发，测试以及部署的独立；

进程隔离：单块架构中的组件更多的是以共享库的形式出现；微服务中的组件是可以独立升级，独立替换掉的部分；不推荐将多个服务部署到同一服务器上；

2.4.2.微服务本质：

服务作为组件；

围绕业务组织团队；

关注产品而非项目：团队负责整个服务的生命周期；

业务数据独立；

技术多样性；

基础设施自动化：微服务架构需要对大量服务进行管控，部署与运维的成本会不断加大，需要更稳定的基础设置自动化设置，能够创建运行环境，安装依赖，部署应用；云技术的推广与使用使得部署和运维的复杂度不断的降低；

演进式架构；

2.4.3.微服务带来的问题：

分布式系统的复杂度：性能，可靠性，异步，数据一致性，工具；

运维成本：配置，部署，监控与告警，日志收集；

部署自动化；

devOps与组织架构；

服务间依赖测试，管理；

3.微服务技术选型比较：

3.1.微服务框架：

Dubbo:

dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，是阿里巴巴SOA服务化治理方案的核心框架。

Spring cloud:

springcloud是由Netflix OSS整合springboot而成的，是Spring Source的产物，有Spring社区的强大支持，还有Pivotal和Netfix是其强大的后盾与技术输出，其中Netflix开源的整套微服务架构套件是Spring Cloud的核心，是面向微服务提供的一整套完整解决方案。

3.1.1基本对比：

1）架构组件完整性对比：



Dubbo自身只是实现了服务治理的基础，其他为保证集群安全、可维护、可测试等特性方面，都需要通过第三方集成来实现。

2）语言使用及web 框架：

都是采用Java语言开发；

dubbo需要与spring框架集成，并且需要发布到tomcat进行部署；

springcloud由springboot组成内嵌tomcat可以以jar的命令直接启动，部署更加简单；

3）社区更新频率：

dubbo基本不再发布更新；

springcloud社区活跃，持续不断更新；

4）RPC vs REST：

RPC方式，服务提供方与调用方接口依赖方式太强；

RPC方式，服务对平台敏感，难以简单复用；

REST风格服务提供方与调用方无依赖性，并且与语言无关；

5）文档质量：

dubbo的文档更加完整，内容更加齐全，细致；

springcloud文档相对而言比较简洁，内容有些部分还不是很齐全，大部分英文为主；

总结：

springcloud提供了一整套完整的微服务解决方案，在各个环节的技术选择上更加灵活，自由；springcloud是对Netflix开源组件的进一步封装，Netflix的开源框架组件已经在Netflix的大规模分布式微服务环境中经过多年的生产实战验证，正逐步被社区接受为构造微服务框架的标准组件。

3.2 微服务框架Spring cloud组件介绍：

3.2.1：服务发现（Eureka）：

Spring Cloud Eureka提供在分布式环境下的服务发现，服务注册的功能。



3.2.2：断路器（Hystrix）：spring cloud Hystrix

断路器(Cricuit Breaker)是一种能够在远程服务不可用时自动熔断(打开开关)，并在远程服务恢复时自动恢复(闭合开关)的设施，Spring Cloud通过Netflix的Hystrix组件提供断路器、资源隔离与自我修复功能。



3.2.3 智能路由（Zuul）：

路由是微服务体系不可或缺的一部分， 例如 / 可以映射到Web 应用， /api/users 可以映射的用户服务 ， api/shop 可以映射到商店服务。 Zuul是一个基于JVM的路由器，同时也是一个服务端负载均衡。 它由Netflix公司开源。



3.2.4 客户端负载均衡（Ribbon）：

Ribbon是一个客户端负载均衡器，能够给HTTP和TCP客户端带来灵活的控制

3.2.5 调用追踪 (spring cloud sleuth) :

SpringCloudSleuth提供了分布式追踪的解决方案



3.2.6 服务配置中心(spring cloud config)：

spring cloud config提供了服务配置的统一处理，并且可以通过以git的提交的方式来触发配置更新，并自动重启相关服务器。

3.2.7 服务消费总线（spring cloud bus）：

spring cloud bus是一个消息服务总线，是对一些消息中间件如kafka，rabbitmq的封装，spring cloud bus可以将消息路由到各个服务中，主要用于对配置信息更新的实时刷新。

3.2.8 消息驱动框架（spring cloud stream)：

SpringCloudStream是一个构建消息驱动的微服务框架



3.2.9 数据混合计算框架(spring cloud data flow)：

Spring Cloud Data Flow是一个混合计算模型，结合了流数据与批量数据的处理方式。开发者可以通过Spring Cloud Data Flow，在诸如数据获取、实时分析、批处理等常见用例中执行数据流的创建与编排。