微服务介绍

微服务、架构与框架

微服务：

微服务是一种概念，是一种思想，它关注的是某一个具体的服务情况，如：服务的大小，服务所提供的功能等等，微服务着重的是一个服务它本身，而不是整体服务之间的关系情况，你也可以这样子理解：微服务相当于我们的模块化开发设计中的模块，一个模块只做一件事情。（微服务的出现就是从模块化设计中演变过来的）。

微服务架构：

微服务架构是一中设计方法，微服务这是应该指使用这种方法的而设计的一种应用。

微服务框架：

微服务与微服务框架不同，如果说微服务是一个概念，一种思想，那微服务架构就是将这种思想具体实现的一种架构工具，微服务架构包括了：服务的构建，服务相互通信与治理两个方面。服务构建就是构建出我们一个个小的服务，而服务治理就是如何将我们构建出的一个个小服务来达到我们最终想要的结果。微服务架构的出现主要是针对我们在开发微服务系统中常见的一些问题：1.客户端如何访问这么多服务，2.这么多服务之间如何通信，如何管理，3.服务挂了怎么办。

微服务架构和整体式架构的区别

单体式应用：

与微服务相对的另一个概念是传统的单体式应用程序( Monolithic application )，单体式应用内部包含了所有需要的服务。而且各个服务功能模块有很强的耦合性，也就是相互依赖彼此，很难拆分和扩容。

单体式应用的优点：

• 开发简洁，功能都在单个程序内部，便于软件设计和开发规划。
• 容易部署，程序单一不存在分布式集群的复杂部署环境，降低了部署难度。
• 容易测试，没有各种复杂的服务调用关系，都是内部调用方便测试。

单体式开发的缺点：

单体程序的缺点一开始不是特别明显，项目刚开始需求少，业务逻辑简单，写代码一时爽，一直爽。噩梦从业务迭代更新，系统日益庞大开始，前期的爽没有了，取而代之的是软件维护和迭代更新的无尽痛苦。

由于单体式应用程序就像一个大型容器一样，里面放置了许多服务，且他们都是密不可分的，这导致应用程序在扩展时必须以「应用程序」为单位。

当里面有个业务模块负载过高时，并不能够单独扩展该服务，必须扩展整个应用程序（就是这么霸道），这可能导致额外的资源浪费。

此外，单体式应用程序由于服务之间的紧密度、相依性过高，这将导致测试、升级有所困难，且开发曲线有可能会在后期大幅度地上升，令开发不易。相较之下「微服务架构」能够解决这个问题。

• 复杂性逐渐提高
• 技术债务逐渐升高
• 维护成本越来越大
• 持续交付周期长
• 可扩展性差

微服务架构的特性：

单一职责：

微服务架构中的每个服务，都是具有业务逻辑的，符合高内聚、低耦合原则以及单一职责原则的单元，不同的服务通过”管道”的方式灵活组合，从而构建出庞大的系统

轻量级通信：

服务之间通过轻量级的通信机制实现互通互联，而所谓的轻量级，通常指语言无关、平台无关的交互方式

独立性：

在微服务架构中，每个服务都是独立的业务单元，与其他服务高度解播，只需要改变当前服务本身，就可以完成独立的开发、测试和部署。

进程隔离：

在微服务架构中，应用程序由多个服务组成，每个服务都是高度自治的独立业务实体，可以运行在独立的进程中，不同的服务能非常容易地部署到不局的主机上。

微服务架构的缺点：

运维要求高：

对于单体架构来讲，我们只需要维护好这一个项目就可以了，但是对于微服务架构来讲，由于项目是由多个微服务构成的，每个模块出现问题都会造成整个项目运行出现异常，想要知道是哪个模块造成的问题往往是不容易的，因为我们无法一步一步通过debug的方式来跟踪，这就对运维人员提出了很高的要求。

分布式的复杂性：

对于单体架构来讲，我们可以不使用分布式，但是对于微服务架构来说，分布式几乎是必会用的技术，由于分布式本身的复杂性，导致微服务架构也变得复杂起来

接口调整成本高：

比如，用户微服务是要被订单微服务和电影微服务所调用的，一旦用户微服务的接口发生大的变动，那么所有依赖它的微服务都要做相应的调整，由于微服务可能非常多，那么调整接口所造成的成本将会明显提高

重复劳动：

对于单体架构来讲，如果某段业务被多个模块所共同使用，我们便可以抽象成一个工具类，被所有模块直接调用，但是微服务却无法这样做，因为这个微服务的工具类是不能被其它微服务所直接调用的，从而我们便不得不在每个微服务上都建这么一个工具类，从而导致代码的重复。

为什么使用微服务

• 开发简单
• 快速响应需求变化
• 随时随地更新
• 系统更加稳定可靠

微服务的几个重要组件：

• 跨语言，跨平台的通信格式：protobuf
• 通信协议：gRPC
• 调度管理服务发现：consul
• 微服务框架： micro
• 部署：docker