欢迎访问我的个人博客：戎码一生
简介
微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理
微服务架构与单体架构
单体架构所有功能模块放在一个单一进程中，并且通过在不同的服务器上面复制这个单体进行扩展。
微服务架构是将每一个功能模块分别放进到一个独立的服务中，并且通过跨服务器分发这些服务进行扩展，只有需要时才复制。
单体应用中，如果需要改动功能，那么则需要重新部署整个单体应用。而微服务则不需要，只需要重新部署修改的功能模块那个微服务。每一个功能模块都是可独立替换和独立维护的软件单元，完全体现了高可复用性，高可维护性，高可扩展性。
面向服务的架构
面向服务的架构（Service Oriented Architecture，SOA）是表示所谓服务的自包含功能单元的一种软件设计原则和架构设计模式。SOA推崇松耦合、复用性和粗粒度的服务设计原则。在企业架构方面，SOA带来的好处包括对业务需求的敏捷交付和迅速反应，通过降低集成成本提高投资回报率，通过复用组件降低开放成本。
SOA：Service Oriented Architecture面向服务的架构。也就是把工程拆分成服务层、表现层两个工程。服务层中包含业务逻辑，只需要对外提供服务即可。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。
微服务体系结构的特征
我们不能说对微服务架构风格有一个正式的定义，但是我们可以尝试描述我们所看到的与“微服务”标签相符的架构的共同特征。与任何概述共同特征的定义一样，并不是所有的微服务架构都具有所有的特征，但是我们确实期望大多数微服务架构具有大多数特征。虽然我们的作者一直是这个相当松散的社区的活跃成员，但我们的目的是尝试描述我们在自己的工作中看到的东西，以及我们所知道的团队的类似努力。特别地，我们并没有给出一些符合要求的定义。
微服务和SOA
当我们已经讨论了微服务之后，一个常见问题为：它是不是就是我们在十年前见到的面向服务的体系架构（SOA，Service Oriented Architecture）。因为微服务风格与SOA所支持的一些主张非常像，这一点是有价值的。然而问题就是SOA意味着太多不同的东西，而且一般因为对ESB在用于集成大型应用时的关注，当大多我们遇到名为“SOA”的东西的时候，它与我们在本文所描述的风格完全不同。尤其我们已经看到了很多面向服务的拙劣的实践——从在ESB[6]中总是将复杂隐藏起来的趋势，到失败的花费数百万而没有价值的多年计划，再到总是抑制变化的集中管理模式，导致有时很难看到过去的这些问题。
当然，微服务社区中许多在用的技术都是由大型组织开发者的集成服务经验发展而来。读者容错模式就是其中的一个例子。web的使用已经为此做出了贡献，使用简单协议是另一种方法，它就是由这些经验衍生出来的——一种远离中心标准的反应，这些标准已经达到了它如今所具有的一种复杂度，直白的说，相当壮观。（当你需要一个实体来管理你的众多实体的时候，你就知道你遇到大麻烦了。）与SOA的共同表现形式已经让微服务主张彻底拒绝被打上SOA的标签，尽管其他人认为微服务就是SOA的一种形式[7]，也许在面向服务方面是没有错的。无论哪种方式，SOA都意味着不同的东西，这意味着使用一个术语来更加简明的定义这种架构风格是有必要的。
微服务社区相对更倾向于另一种方法：智能终端和无声管道。使用微服务搭建的应用旨在尽可能的分解和凝聚——他们拥有他们自己的业务逻辑，而且更像一个传统Unix印象中的过滤器——接收请求，应用合适的逻辑，并产生响应。它们使用简单REST协议而非复杂协议，就像WS-Choreography或者BPEL或者使用中央工具配置。
这两种协议使用的比较多的是使用源API和轻量级消息的HTTP请求-响应[8]。第一个最好的表达是
属于web，而不落后于web --Ian Robinson
微服务团队使用万维网(以及很大程度上，Unix)构建的原则和协议。开发者或操作人员可以通过较少的努力来缓存经常使用的资源。
第二种常用方法是通过轻量级总线传递消息。选择的基础设施素来愚蠢（愚蠢是因为仅作为消息路由器）——像RabbitMQ或ZeroMQ一样不仅仅是提供可靠的异步架构来简单实现——智能仍然存在于生产和消费信息的终点上；在服务中。
在整体结构中，正在执行中的组件通过方法调用或函数调用进行通信。将一个巨大的框架改成一个微服务框架时遇到的最大的问题在于改变通信方式。从内存的方法调用到RPC的简单转换会使通信性能变差。相反，你需要用粗粒度方法来替换细粒度的通信。
微服务设计原则
单一职责原则
意思是每个微服务只需要实现自己的业务逻辑就可以了，比如订单管理模块，它只需要处理订单的业务逻辑就可以了，其它的不必考虑。
服务自治原则
意思是每个微服务从开发、测试、运维等都是独立的，包括存储的数据库也都是独立的，自己就有一套完整的流程，我们完全可以把它当成一个项目来对待。不必依赖于其它模块。
轻量级通信原则
首先是通信的语言非常的轻量，第二，该通信方式需要是跨语言、跨平台的，之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性，可以不受技术的钳制。
接口明确原则
由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初就要考虑到所有情况，让接口尽量做的更通用，更灵活，从而尽量避免其它模块也做调整。
微服务优势与缺点
特性
1.每个微服务可独立运行在自己的进程里；
2.一系列独立运行的微服务共同构建起了整个系统；
3.每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理，用户管理等；
4.微服务之间通过一些轻量级的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。
特点
- 易于开发和维护
由于微服务单个模块就相当于一个项目，开发这个模块我们就只需关心这个模块的逻辑即可，代码量和逻辑复杂度都会降低，从而易于开发和维护。
- 启动较快
这是相对单个微服务来讲的，相比于启动单体架构的整个项目，启动某个模块的服务速度明显是要快很多的。
- 局部修改容易部署
在开发中发现了一个问题，如果是单体架构的话，我们就需要重新发布并启动整个项目，非常耗时间，但是微服务则不同，哪个模块出现了bug我们只需要解决那个模块的bug就可以了，解决完bug之后，我们只需要重启这个模块的服务即可，部署相对简单，不必重启整个项目从而大大节约时间。
- 技术栈不受限
比如订单微服务和电影微服务原来都是用java写的，现在我们想把电影微服务改成nodeJs技术，这是完全可以的，而且由于所关注的只是电影的逻辑而已，因此技术更换的成本也就会少很多。
- 按需伸缩
我们上面说了单体架构在想扩展某个模块的性能时不得不考虑到其它模块的性能会不会受影响，对于我们微服务来讲，完全不是问题，电影模块通过什么方式来提升性能不必考虑其它模块的情况。
###缺点
- 运维要求较高
对于单体架构来讲，我们只需要维护好这一个项目就可以了，但是对于微服务架构来讲，由于项目是由多个微服务构成的，每个模块出现问题都会造成整个项目运行出现异常，想要知道是哪个模块造成的问题往往是不容易的，因为我们无法一步一步通过debug的方式来跟踪，这就对运维人员提出了很高的要求。
- 分布式的复杂性
对于单体架构来讲，我们可以不使用分布式，但是对于微服务架构来说，分布式几乎是必会用的技术，由于分布式本身的复杂性，导致微服务架构也变得复杂起来。
- 接口调整成本高
比如，用户微服务是要被订单微服务和电影微服务所调用的，一旦用户微服务的接口发生大的变动，那么所有依赖它的微服务都要做相应的调整，由于微服务可能非常多，那么调整接口所造成的成本将会明显提高。
- 重复劳动
对于单体架构来讲，如果某段业务被多个模块所共同使用，我们便可以抽象成一个工具类，被所有模块直接调用，但是微服务却无法这样做，因为这个微服务的工具类是不能被其它微服务所直接调用的，从而我们便不得不在每个微服务上都建这么一个工具类，从而导致代码的重复。
微服务开发框架
目前微服务的开发框架，最常用的有以下四个：
- Spring Cloud：http://projects.spring.io/spring-cloud（现在非常流行的微服务架构）
- Dubbo：http：//dubbo.io
- Dropwizard：http://www.dropwizard.io （关注单个微服务的开发）
- Consul、etcd&etc.（微服务的模块）
负载均衡
负载均衡的常见策略
- 随机
把来自网络的请求随机分配给内部中的多个服务器。
- 轮询
每一个来自网络中的请求，轮流分配给内部的服务器，从1到N然后重新开始。此种负载均衡算法适合服务器组内部的服务器都具有相同的配置并且平均服务请求相对均衡的情况。
- 加权轮询
根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。例如：服务器A的权值被设计成1，B的权值是3，C的权值是6，则服务器A、B、C将分别接受到10%、30％、60％的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用率，避免低性能的服务器负载过重。
- IP Hash
这种方式通过生成请求源IP的哈希值，并通过这个哈希值来找到正确的真实服务器。这意味着对于同一主机来说他对应的服务器总是相同。使用这种方式，你不需要保存任何源IP。但是需要注意，这种方式可能导致服务器负载不平衡。
- 最少连接数
客户端的每一次请求服务在服务器停留的时间可能会有较大的差异，随着工作时间加长，如果采用简单的轮循或随机均衡算法，每一台服务器上的连接进程可能会产生极大的不同，并没有达到真正的负载均衡。最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在处理的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器，使均衡更加符合实际情况，负载更加均衡。此种均衡算法适合长时处理的请求服务，如FTP。
欢迎访问我的个人博客：戎码一生
来源：https://blog.csdn.net/qq_38019452/article/details/100982786