契约测试Pact(一)

什么是微服务

微服务的具体定义

集群、分布式、微服务概念和区别

集群是个物理形态，分布式是个工作方式。

分布式：一个业务分拆成多个子业务，部署在不同的服务器上

集群：同一个业务，部署在多个服务器上

 

分布式中的每一个节点，都可以做集群。而集群并不一定就是分布式的。

简单说，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。

 

例如：一个任务是由10个子任务组成，每个子任务单独执行需要1小时，则在一台服务器上执行该服务需10个小时。

采用分布式方案，提供10台服务器，每台服务器只负责处理一个子任务，不考虑子任务间的依赖关系，执行完成这个任务只需1个小时。

而采用集群方案，同样提供10台服务器，每台服务器都能独立处理这个任务。假设有10个任务同时到达，10个服务器将同时工作，1小时后，10个任务同时完成，这样，整体看，还是1小时内完成1个任务。

 

微服务

一个大型复杂软件应用-由一个或多个微服务组成。

系统中的各个微服务可以独立部署，各个微服务之间是松藕组合的。每个微服务仅关注与完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务员能力。

各个微服务既可以看做一个独立的系统，也可以把这些微服务组合成一起看成一个系统。

 

分布式是否属于微服务？

答案是肯定的。微服务的意思就是将模块拆分成一个独立的服务单元通过接口来实现数据的交互。

 

微服务的设计是为了不因为某个模块的升级和BUG 影响现有的系统业务。微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上，他也可以是同一个服务器。

 

 

 

 

 

特点：

 从本质上来说，微服务是一种架构模式

 是面向服务型架构（SOA）的一种变体(好处是系统未来的扩展性变得很强)

              本子上还是SOA，但微服务不像SOA那样要求绑定具体的技术。微服务鼓励用恰当的技术去

              实现合适的服务，这样系统的扩展性会变得很强

 每个服务运行在独立的进程中，服务与服务之间用 Rest API来进行沟通，把不同的服务有机的整合成统一的系统。

 每个服务都围绕着具体业务进行构建，能够被独立部署到类生产环境中。

 

SOA架构和微服务架构的区别

首先SOA和微服务架构一个层面的东西，而对于ESB和微服务网关是一个层面的东西，一个谈到是架构风格和方法，一个谈的是实现工具或组件。

 

 1.SOA（Service Oriented Architecture）“面向服务的架构”:他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。

 

 2.微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

 

 微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想

 

对比

 微服务更容易的扩展，它基本上是独立的，不可分割的，更容易的发布新的版本。SOA的组件一般比较大型，发布新版本一般更复杂，需要专门的运维团队除了，微服务自己团队就行了。(允许意见不一致)

 微服务可以采用不同的技术栈进行组合，而SOA架构，每个组件都需要了解通用的交流组件，一般被认为是ESB。

 SOA中因为涉及到ESB，可能会出现单点故障。而微服务每个服务故障只会影响当前的服务。

相同点：

 两者都是为了处理复杂架构而出现的分布式系统，都需要系统直接的通信，协调

SOA与微服务的主要区别在大小和范围上，微服务一般比SOA的粒度更细。SOA也有可能是一个大的组件，或者内部包含了多个微服务。

 

 

为什么需要微服务

LAMP（Linux+Apache+MySQL+PHP）

MVC（Spring+MyBatis/Hibernate+Tomcat）

单体式架构（Monolithic Architecture）

 

 

微服务与传统开发方式的区别

单体式架构(Monolithic Architecture)

 

 

 

 

单体服务结构简单，代码是一个统一的工程，容易开发、部署和维护。但是，正由于此，各个模块耦合严重，当工程大到一定程度后，会带来一系列的问题。

 

优点：

 团队组织结构简单，便于集中管理

 开发进度一致，统一管理，能够避免重复开发的问题

 所有的功能都在贝蒂，没有远程调用的开销和网络损耗

缺点：

 效率低

 维护困难

 不够灵活

 稳定性不好

 扩展性不够

 

 微服务架构

 

 

优点：

 解决单体架构存在的一系列问题

 部署、回滚变得简单、更敏捷

 每个服务都可以独立扩容

 不同的业务特征选择合适的技术方案，有针对性解决具体业务问题

 可以运用插件的形式更新新功能，不必有一点扩充，就要重新部署整个项目

 自主管理相关的业务，可以随业务的发展提供数据接口集成，而非以数据库的方式同其他服务集成

 对于业务数据可以采用接口的方式来方便未来业务员发展后的数据管理与数据迁移

缺点：

 不同的子系统交由不同的团队开发，这个会增加整个系统内部的通信需求，也会增加不同团队的交流通成本

 对于子系统的测试来说，微服务的分布式架构大大的提高了测试的复杂度

 分布式部署对于团队的DevOps能力要求很高

 随着服务数量的增加，管理的复杂程度呈指数级增加