微服务概述

事情总在发展，大型软件系统架构也随着软件开发技术、基础配套设备和硬件性能等因素地改变而不断演化。一般来说， 早期的软件大多数是单体架构，接着使用分层技术演化为垂直架构，然后SOA面向服务架构和微服务架构相继登场，最终随着云技术的应用和推广，孕育出云原生架构的思想。下面将会一一介绍这些架构设计的基础理念和优缺点。

在Wab应用程序发展的早期，大部分项目将所有的服务增功能模块打包成单个巨石型(Monolih) 应用，譬如很多企业的lva应用程序打包为war包.

单体架构具有易于搭建开发环境、易于测试和部署等优势， 但其缺陷也非常明显，进行局部改动就需要重新部署，而且编译时间过长。单体架构的技术栈也不易扩展，只能不断地在原有基础上进行局部优化，比如说应用的某一部分场景需要处理高并发，使用Go语言较为合适，但是单体架构并不支持多语言技术栈，也就只好作罢。

当访问量逐渐增大，单体架构使用增加机器的方法带来的性能优化效用越来越小，单体架构不同业务部分所需要的机器数量和性能差异也越来越大，为了提升机器利用率和性能，单体架构往往会演化为垂直架构。垂直架构就是以单体架构规模的项目为单位进行垂直划分，将大应用拆分成一个个单体结构的应用。但是，拆分后的单体架构之间存在数据沉余，耦合性较大等问题。垂直分层架构中项目之间的接口多为数据同步功能，如:不同项目之间的数据库，通过网络接口进行数据库同步。

垂直架构就是彼此存在依赖关系的组件组成的架构，比如分层:界面表示层依赖业务逻辑，而业务逻辑依赖数据库访问

分层是一个典型的对复杂系统进行结构化思考和抽象聚合的通用性方法。MVC则是一种常见的三层结构架构模式。它将应用分为标准的三层:数据访问层、服务层和Web层。(1)数据访问层用于定义数据访问接口，实现对真实数据库的访问:

(2)服务层用于对应用业务逻辑进行处理:

(3) Web层用于处理异常、逻辑跳转控制和页面渲染模板等。

垂直分层架构的优点，首先是项目架构简单，前期开发成本低并且周期短，是小型项目的首选:其次通过垂直拆分，原来的单体项目不至于无限扩大。除此之外，不同的项目可采用不同的技术。但是垂直分层架构也存在全部功能集成在一个工程中的问题，对于大型项目不易开发、扩展及维护:系统性能扩展只能通过扩展集群结点来实现，成本高并且有瓶颈。

当垂直架构拆分的应用越来越多，就会出现多个应用都依赖的业务逻辑组件，井且各个应用进行交互的需求越来越频繁。此时，就需要将部分通用的业务组件独立出来，并定义好服务间交互的接口，向外提供能力，让其他服务调用，恰巧这时出现了大型的网络服务提供商，这些企业依靠出售自身软件能力来赚取盈利，其他小型企业可以使用这些企业的对外服务，所以SOA面向服务架构应运而生。它带来了模块化开发、分布式扩展部署和服务接口定义等相对宽泛的概念。

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

实施SOA的关键目标是实现企业I资产的最大化作用，也就是建立企业服务总线，外部应用通过企业总线调用服务。要实现这一目标，就要在实施SOA的过程中车记以下特征:可从企业外部访问、随时可用、粗粒度的服务接口分级，松散得合、可重用的服务、服务接口设计管理、标准化的服务接口、支持各种消息模式和精确定义的服务契约

SOA 服务架构都具有有平台独立的自我描述XML文档，例如WEB服务描述语言的标准。这种服务架构可以提供一个业务规则引襄(Bsies Rales Egine)；该引擎容许业务规则被合并在一个服务里或多个服务里、这种架构也提供了一个服务管理基础架构(Service Mangement fitoctur),用来管理服务，提供类似审核、列表Cilling)、 日志等功能。此外，该架构给企业提供了更活的业务流程，更好地处理控制请求(Regulatory Requirement)，例如Sarbanes Oxley(SOX),并且可以在不影响其他服务的情况下更改某项服务。

SOA架构的优点:

1. 将重复的功能抽取为服务，提高开发效率，提高系统的可重用性和可维护性。
2. 可以针对不同服务的特点制定集群及优化方案。
3. 采用ESB减少系统中的接口耦合。
4. 借助现有的应用来组合产生新服务的敏捷方式，提供给企业更好的灵活性来构建应用程序和业务流程。

SOA架构适用于大型软件服务企业对外提供服务的场景，对于一般业务场景并不适用，其服务的定义、注册和调用都需要较为繁琐的编码或者配置实现，并且业务总线也容易导致系统的单点风险并拖累整体性能。

随着互联网浪潮的来临，越来越多的中小微企业推出面向普通大众的网站或者应用。这些企业不同于大型软件服务企业，没有能力也无需构建SOA所依赖的ESB企业服务总线。于是继承SOA众多优点和理念的微服务架构于2014年由Matrin Fowler 提出，其理念是将业务系统彻底地组件化和服务化，形成多个可以独立开发、独立部署和独立维护的服务或者应用的集合，以应对更快的需求变更和更短的开发迭代周期。

微服务是一种架构模式，它提倡将单一应用程序划分成一 组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。

微服务也是种架构风格，它提倡大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成单一职责。在一般情况下，每个职责代表着一个小的高内聚的业务能力。

如康威定律所言，任何组织在设计一套系统(广义概念)时，所交付的设计方案在结构上都与该组织的通信结构保持一致，微服务不仅仅是技术架构的变化，还包含了组织方式和沟通方式的变化，开发团队需要形成适合微服务开发的组织架构和沟通方式。

微服务与面向对象设计中的原理同样相通，都是遵循单一职责、关注分离、模块化与分而治之等基本的原则

总得来说，微服务架构有如下的特点:

1. 系统服务层完全独立出来，并将服务层抽取为一个一个的微服务。
2. 微服务遵循单一原则。
3. 微服务之间采用RESTful等轻量协议通信。
4. 微服务一般使用容器技术部署，运行在自己的独立进程中，合理分配其所需的系统资源。
5. 每个微服务都有自己独立的业务开发活动和周期。

微服务架构下服务拆分粒度更细，有利于资源重复利用，提高开发效率:开发者可以更加方便地制定每个服务的优化方案，提高系统可维护性。除此之外，微服务架构采用去中心化思想，服务之间采用RESTful等轻量协议通信，相比ESB更轻量.这种架构设计，更适用于互联网时代的产品敏捷迭代开发。

但是，微服务架构拆分的服务实例如果过多，服务治理成本会极大升高，不利于系统维护:服务之间相互依赖，有可能形成复杂的依赖链条，往往单个服务异常，其他服务都会受到影响，出现服务雪崩效应:服务实例之间交互需要处理分布式事务、调用幂等和重试等问题，开发成本高，对团队挑战大。

正如前文所说，微服务维承了 SOA的众多优点和理念，两种架构都属于典型的、包含松属合分布式组件的系统结构。在国绕着服务的概念构建架构这一方面，微服务提供了一种更来斯、定义更好的方式。但是不能简单地说一种架构比另种架构更好，生要是歌关于构建的应用程序。有些应用程序适合使用微服务架构，有些则适合50元，主i9更道合与许多其他应用程序集成的大型复染企业应用程序环境。小型的应用现摩波许井不通合使月50聚构， 因为它不需要便用消息中间件值件，用微出务美的理合于较小和良好的分割式Web业务系统。

微服务不再强调SOA架构中比较重要的ESB企业服务总线，而是通过轻量级通信机制相互沟通。SOA的ESB企业总线太过于复杂，大大增加了系统的复杂性和可维护性。所以微服务架构中采用了像Restful API这样更加轻量级的通信机制。

SOA注重的是系统集成，而微服务关注的则是完全分离。两者之间最关键的区别在于微服务专注于以自治的方式产生价值。两种架构背后的意图是不同的: SOA尝试将应用集成，一般采用中心化管理来确保各应用能够协同运作。微服务尝试部署新功能，快速有效地扩展开发团队，它着重于分散管理、代码再利用与自动化执行。

在第一章中，本书介绍了云原生的相关概念。Pivolal 和Google是云原生应用的早期贡献者和推广者，推出了相应的书籍并成立了云原生计算基金会(CNCF)

微服务不再强调SOA架构中比较重要的ESB企业服务总线，而是通过轻量级通信机制相互沟通。SOA的ESB企业总线太过于复杂，大大增加了系统的复杂性和可维护性。所以微服务架构中采用了像Restful API这样更加轻量级的通信机制。

SOA注重的是系统集成，而微服务关注的则是完全分离。两者之间最关键的区别在于微服务专注于以自治的方式产生价值。两种架构背后的意图是不同的: SOA尝试将应用集成，一般采用中心化管理来确保各应用能够协同运作。微服务尝试部署新功能，快速有效地扩展开发团队，它着重于分散管理、代码再利用与自动化执行。

云原生应用程序可以简单地定义为完全为云计算架构而构建的应用程序。这意味着如果应用程序最终部署在云上，并且依赖云服务提供的分布式或者其他基础架构，它城是云原生的。CNCF也对云原生进行了重新定义:云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用:云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API;云原生的四要素是微服务、容器化、DevOps和持续交付。

云原生架构所依托的PaaS产品可以为整个服务开发、发布和运维过程提供支持，分别是Codeless. plcationles和Sreress.

• Codeless 对应的是服务开发，实现了源代码托管， 工程师只需要关注代码实现，而不需要关心代码在哪，因为在整个开发过程中工程师都不会感受到代码库和代码分支的存在。
• Aplcationless对应的是服务发布:在服务化框架下，工程师的服务发布不再需安申请应用发布权限，也不需要关注他的应用如何发布
• Serverless 对应的则是服务运维:有了Serverless 化能力，工程师不再需要关注机器资源，Servlerless 会帮开发者搞定机器资源的弹性扩缩容。

这些技术组合搭配，能够构建容错性好、易于管理和便于观察的松耦合系统;再结合可靠的自动化手段，云原生技术能够使工程师轻松地对系统作出频繁和可预测的重大变更。由此可见，云原生是保障系统能力的有效手段:云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。但是，云原生同样存在着一定的限制，云原生API不是跨云平台的，应用在各大公用云提供商之间切换存在迁移成本，比如说AWS和微软的Azure。

近几年，随着微服务架构的火热，也出现了很多微服务框架

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器和数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。SpringCloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Bo风格进行再封装，屏蔽掉了复杂的配置和实现原理。最终给开发者留出了一套简单易值、易部署和易维护的分布式系统开发工具包。Spring Cloud 的子项目大致可分成两类，一类是对现有成熟框架Spring Boot化的封装和抽象，也是数量最多的项目，如Netnix Eureka、Netfix Hlystrix、Netnix Zuul等:第二类是开发了一部分分布式系统的基础设施的实现，如统配置管理中心 Spring Config.

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，Dubbo就是个远程服务注册、调用和管理的分布式框架。Dubbo 自2008年开始在阿里内部使用，2011 年开源，2014 年开始停止更新，直至2017年重新开始更新。

Dubbo 框架由5个部分组成

• Provider 是暴露服务的服务提供方
• Consumer是调用远程服务的服务消费方
• Registry是服务注册与发现的注册中心
• Monitor为统计服务的调用次调和调用时间的监控中心
• Container 为服务运行容器。

Dubbo的特点，主要可以总结为以下3个方面:

1. 远程通信:提供对多种基于长连接的NIO框架的统一抽象封装， 支持非阻塞V/O的通信库(比如Mina、Netty和Grizzly),包括多种线程模型、序列化(Hessian2/ProtoBuf)以及请求-响应模式的信息交互方式。
2. 集群容错:提供基于接口方法的透明远程过程调用(RPC)，包括多协议支持(自定义RPC协议)以及软负载均衡(Ranom/RoundRobin)、失败容错(ailoverFailback),地址路由和动态配置等集群支持。
3. 自动发现:基于注册中心目录服务，使服务消费方能动态地查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

从如上的介绍就可以知道，Dubbo和SpringCloud的关注点并不相同，Dubbo更专注于RPC领域，Spring Cloud一个重服务的全方位框架。

一些文章在谈到微服务的时修候总是拿Spring Cloud和Dubbo来对比，需要强调的是Duto未来的定位并不是要成为一个微服务的全面解决方案，而是专注在RPC领城，其官网上也将其定义为AHigh prformanmcJava PRC framework.所以，Dubbo 应该是微服|务生态体系中的通信机制的重要组件之一，

鼠然微服务架构的实政落地独立于编程语言，归是C0语言在微服务架构的落地中心有其极行的优势，因此，错音的微服务框架也相值酒现，各方面都较为优秀的有Go Kit和Go Micro等。

Go语言本身十分轻量级，运行效率极高，同时对并发编程有着原生的支持，从而能更好的利用多核处理器，内置noct 标准库对网络开发的支持也十分完善。Go语言相对其他语言具有以下几点的优势

1. 语法简单，上手快.简单易学，Go语言的作者推崇C语言的简单而强大，所以Go语言提供的语法一般都十分简洁。 Go语言关键字只有25个，但是表达能力很强大，几乎支持大多数现代语言常见的特性:比如继承、重载和对象等。
2. 强类型的静态语言，却又具备有动态语言的开发效率和优势。静态类型的语言可以在编译的时候检查出来隐藏的大多数问题，但是Go语言提供了类型推导机制，解决了强类型的静态语言在开发效率上的问题。
3. 原生支持井发，协程模型是非常优秀的服务端模型，同时也适合网络调用。这是Go语言最大的特色，天生地支持并发，Go语言就是基因里面支持并发，可以充分的利用多核。
4. 丰富的标准库，Go语言目前内置了大量的库，开箱即用，方便开发者。(5)部署方便，编译包小， 可直接编译成机器码，不依赖其他库。
5. Go语言提供了便多开发工具链，包色括代码n工具包管理系线、测试框架等，方便进行团队化开发。
   最容易实现微服务，在性能、易用性和生态等方面都拥有优势。

Go-kit 是C语言工具包的集合，可精助工程师构建强大、可靠和可维护的微服务。Go-kit 就提供了用于实现系统监控和弹性模式组件的库，例如日志记录、跟踪，限流和熔断等。

除了用于构建微服务的工具包之外，Go-kit 为工程师提供了提供良好的架构设计原则示范。Go-kit 提倡工程师使用Alistair Cockburn提出的SOLID设计原则、领域驱动设计(DDD)。所以Go-kit不仅仅是微服务工具包，它也非常适合构建优雅的整体结构。

基于Go-kit的应用程序架构由三个主要部分组成:传输层、接口层和服务层。

• 传输层用于网络通信，服务通常使用HTTP或gRPC等网络传输方式，或使用NATS等发布订阅系统相互通信。除此之外，Go-kit 还支持使用AMQP和Thrift等多种网络通信模式。
• 接口层是服务器和客户端的基本构建块。在Go-kit 中服务中的每个对外提供的接口方法都会定义为一个端点(Endpoint)， 以便在服务器和客户端之间进行网络通信。每个端点使用传输层通过使用HTTP或gRPC等具体通信模式对外提供服务。
• 服务层是具体的业务逻辑实现。服务层的业务逻辑包含核心业务逻辑，它不会也不应该进行HTTP或gRPC等具体网络传输，或者请求和响应消息类型的编码和解码。Go-kit在性能和扩展性等各方面表现优异。本书介绍的大部分微服务组件，都将基于Go-kit框架进行实例讲解。

Go Micro是基于Go语言实现的插件化RPC微服务框架，提供了服务发现、负载均衡、同步传输、异步通信以及事件驱动等机制，它尝试去简化分布式系统间的通信，让开发者可以专注于自身业务逻辑的开发。

go-micro是组件化的框架，每一个基础功能都是一个interface，方便扩展。同时，组件又是分层的，上层基于下层功能向上提供服务，整体构成go-micro框架。
go-micro的组件包括：

• Registry组件：服务发现组件，提供服务发现机制：解析服务名字至服务地址。目前支持的注册中心有consul、etcd、 zookeeper、dns、gossip等
• Selector组件：构建在Registry之上的客户端智能负载均衡组件，用于Client组件对Registry返回的服务进行智能选择。
• Broker组件：发布/订阅组件，服务之间基于消息中间件的异步通信方式，默认使用http方式，线上通常使用消息中间件，如Kafka、RabbitMQ等。
• Transport组件：服务之间同步通信方式。
• Codec组件：服务之间消息的编码/解码。
• Server组件：服务主体，该组件基于上面的Registry/Selector/Transport/Broker组件，对外提供一个统一的服务请求入口。
• Client组件：提供访问微服务的客户端。类似Server组件，它也是通过Registry/Selector/Transport/Broker组件实现查找服务、负载均衡、同步通信、异步消息等功能。

微服务之间通信
两个微服务之间的通信是基于C/S模型，即服务发请求方充当Client，服务接收方充当Server。