什么是微服务？一看就会系列！

      近年来随着互联网的快速发展，尤其是移动互联网以及云计算的迅猛发展，对于软件交付与迭代速度和效率的要求在不断提高。微服务架构凭借其简单清晰、灵活可扩展、独立部署等优势，越来越成为了分布式架构中的主流。现在微服务成了面试的必备知识，感觉不会微服务真的很难找工作！一直在热点上的微服务到底是什么？那本篇文章就从它的演变过程来了解它。

一、微服务架构的演变

微服务是一种服务间松耦合的、每个服务之间高度自治并且使用轻量级协议进行通信的可持续集成部署的分布式架构体系。这一句包含了微服务的特点，微服务架构和其他架构有什么区别？以下对比一些常见的架构。

1、单体结构

单体架构是最简单的软件架构，常用于传统的应用软件开发以及传统 Web 应用。传统 Web 应用，也就是大家早期所学习的ssm或者ssh项目，采用分层架构模式，数据库访问层、业务逻辑层、控制层、从前端到后端的代码都放到同一个项目一般是将所有功能模块都打包（jar、war）在一个 Web 容器（JBoss、Tomcat）中部署、运行。

单体结构图：

优点：

1）开发简单 
项目搭建速度快，容易运行和测试
2）运维简单
整个项目就一个war包，部署特别方便
3）定位bug问题迅速
就一个应用，排查问题容易

缺点：

1）不适用协同开发
随着业务复杂度增加、技术团队规模扩大，在一个单体应用中维护代码，会降低开发效率。比如你开发完某一个功能模块，而你需要需要调用你同事开发某一功能开发模块，你就需要等你同事也开发完才可以部署测试。
2）部署频率低
随便代码的增多，首先部署会越来越消耗时间，还有我们在修复一个很小很小的bug的时候整个项目都要重新部署，所以我们会集中一个时间点部署多个需求。
3）可靠性差
这个很容易理解，假如某个影响出现了死循环，导致内存溢出，会影响整个项目挂掉。
4）扩展性差
我们在新增业务的时候，代码层面会考虑在不影响现有的业务基础上编写代码，提高了代码的复杂性。
5）复杂性高
随着业务的不断迭代，项目的代码量会急剧的增多，项目模块也会随着而增加，模块与模块之间的关系就会变成的很复杂，整个项目就会变成的非常复杂，在新增和修改代码的时候都会做很多的测试，很容易会由于一处的变动影响之前业务的功能。

适用场景：*项目、管理系统、crm、oa、适用于个人小团队开发。

2、集群结构

最初我们架构是垂直的，所有功能都在一个项目里面 随着业务和用户的增长，原来一台服务器已经不能支撑现有的请求数，这个时候我们就需要部署多台服务器，这时候就出现了集群，单机处理到达瓶颈的时候，你就把单机复制几份，这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍（有几个节点就相当于提升了这么多倍）。

集群的特点：
1）就是通过多台计算机共同完成同一项工作，达到更高的效率。两机或多机机器同时工作。
2）如果一台机器出现故障，另一台机器可以起作用。

 我们再来举个通俗易懂的例子。

你开了家小餐馆，由于资金有限，只聘请了一位厨师张工，配菜切菜备料炒菜张工一个人全包了。后来生意越来越好了，张工根本忙不过来，于是再请了一位厨师李四，张工和李四两人一起负责厨房一切事宜，他俩的关系是集群。张工有时候有事请假了，没事，还有李四在。

集群结构图：

优点：

1）扩展能力强
其他扩展技术，通常仅能支几十个CPU的扩展，扩展能力有限，而采用集群技术的集群系统则可以扩展到包括成百上千个CPU的多台服务穗，扩展能力具有明显优势。集群服务还可不断进行调整，以满足不断增长的应用需求。当集群的整体负荷超过集群的实际能力时，还可以添加额外的节点。
2）实现方式容易
服务器集群技术相对其他扩展技术来说更加容易实现，主要是通过软件进行的。在硬件上可以把多台性能较低、价格便宜的服务器，通过集群服务集中连接在一起即可实现整个服务器系统成倍，甚至几十几百倍地增长。无论是从软硬件构成成本上来看，还是从技术实现成本上来看，都较其他扩展方式更低。
3）高可用性
使用集群服务拥有整个集群系统资源的所有权，如磁盘驱动器和IP地址将自动地从有故障的服务器上转移到可用的服务器上。当集群中的系统或应用程序出现故障时，集群软件将在可用的服务器上重启失效的应用程序，或将失效节点上的工作分配到剩余的节点上。在切换过程中，用户只是觉得服务暂时停顿了一下。
4）易管理性
可使用集群管理器来管理集群系统的所有服务器资源和应用程序，就像它们都运行在同一个服务器上一样。可以通过拖放集群对象，在集群里的不同服务器间移动应用程序，也可以通过同样的方式移动数据，还可以通过这种方式来手工地平衡服务器负荷、卸载服务器，从而方便地进行维护。同时，还可以从网络的任意地方的节点和资源处，监视集群的状态。当失效的服务器连回来时，将自动返回工作状态，集群技术将自动在集群中平衡负荷，而不需要人工干预。

缺点：

1）服务器切换耗时久
虽然集群技术很牛逼，但很多程序只能在一台服务器上进行，当这台服务器出现了应用上的故障，其他的服务器就要重启侦测并确认、后备服务器启动、接管数据共享区三个步骤，在服务器切换的过程中耗时较久，随着应用量变大，所需时间越久。
2）当你的业务发展到一定程度的时候，你会发现一个问题——无论怎么增加节点，貌似整个集群性能的提升效果并不明显了。

3、分布式结构

分布式就好比是一个蜂巢的结构，当某一天使用单体架构发现很难推进需求的开发，很多企业会开始做单体服务的拆分，就是将多软件架构设计分散开来，把不同的业务功能拆成不同的工程节点，由各个不同的节点组成，每个节点都有不同的功能，且布置在不同的服务器上，各节点之间相互连接、相互请求从而实现整个系统的功能。拆分的方式一般有水平拆分和垂直拆分。
垂直拆分是把一个应用拆成松耦合的多个独立的应用，让应用可以独立部署，有独立的团队进行维护。
水平拆分是把一些通用的，会被很多上层服务调用的模块独立拆分出去，形成一个共享的基础服务，这样拆分可以对一些性能瓶颈的应用进行单独的优化和运维管理，也在一定程度上防止了垂直拆分的重复造*。

 我们再来举个通俗易懂的例子。

单体服务如果相当于一个快餐店，所有的服务员职责都是一样的，又要负责收银结算，又要负责做汉堡，又要负责端盘子，又要负责打扫，服务员之间不需要有交流，用户来了后，服务员从前到后负责到底。分布式相当于让服务员有职责分工，收银员负责收银，厨师负责做汉堡，保洁阿姨负责打扫等，所有服务员需要用同一种语言交流，方便工作协调。

假设需要开发一个在线商城。把它按照功能模块拆分成多个独立的服务，如：用户服务、产品服务、订单服务、后台管理服务、数据分析服务等等。这一个个服务都是一个个独立的项目，可以独立运行。为某一节点添加服务器。如果服务之间有依赖关系，那么通过RPC方式调用。可以独立开发、独立部署、独立测试。

优点：

1)增大系统容量
我们的业务量越来越大，而要能应对越来越大的业务量，一台机器的性能已经无法满足了，我们需要多台机器才能应对大规模的应用场景。所以，我们需要垂直或是水平拆分业务系统，让其变成一个分布式的架构。
2)加强系统可用
我们的业务越来越关键，需要提高整个系统架构的可用性，这就意味着架构中不能存在单点故障。这样，整个系统不会因为一台机器出故障而导致整体不可用。所以，需要通过分布式架构来冗余系统以消除单点故障，从而提高系统的可用性。
3)解耦合、重用度更高
将项目进行模块拆分成多个独立的服务，各个服务之间进行调用重用度更高，系统之间用接口通信。
4）扩展性强
项目拆分，不同的团队负责不同的子项目，团队协作流程也会得到改善。利于扩展，增加功能，只需增加子项目，调用其他系统接口就好了。
5）部署便捷
因为软件服务模块被拆分，开发和发布速度可以并行而变得更快

缺点：

1）架构设计变得复杂（尤其是其中的分布式事务）
2）部署单个服务会比较快，但是如果一次部署需要多个服务，部署会变得复杂
3）系统的吞吐量会变大，但是响应时间会变长
4）运维复杂度会因为服务变多而变得很复杂
5）架构复杂导致学习曲线变大
6）测试和查错的复杂度增大
7）技术可以很多样，这会带来维护和运维的复杂度
8) 管理分布式系统中的服务和调度变得困难和复杂

4、soa架构

虽然 ，目前 不同厂商或个人对SOA有着不同的理解，但是 对于 SOA的几个关键特性 的认识却是一致的 ：一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。

用途：SOA解决多服务凌乱问题，SOA架构解决数据服务的复杂程度，同时SOA又有一个名字，叫做服务治理。

特点：采用soap协议传输（Http/Https/XML）实时传输，在高并发的情况下实现通讯该协议存在冗余性传输，而且非常占用带宽。后来使用json代替了xml。

随着我们系统的进一步复杂度的提示，我们不得不进一步对系统的性能进行提升，我们将多个模块分成多个子系统，多个子系统直接互相调用（因为SOA一般用于大型项目，比较复杂，所以一般总系统不会再集成，会拆分多个，分别做成服务，相互调用）。当我们的电商UI进行一个下订单的任务时，多个服务直接互相调用，系统通过数据总线，分别调用对于的子系统即可。

SOA主要的使用场景，如下图：


通过上面的图我们可以看出，多个子系统直接相互交互，相互调用非常凌乱，这样我们就很不爽，所以我们就用到了我们的SOA架构，SOA又叫服务治理，SOA就是帮助我们把服务之间调用的乱七八糟的关系给治理起来，然后提供一个统一的标准，把我们的服务治理成下图所示，以前我们的服务是互相交互，现在是只对数据总线进行交互，这样系统就变得统一起来。
 

Tip：统一标准：各系统的协议、地址、交互方式。
新的交互方式：各个系统分别根据统一标准向数据总线进行注册，各子系统调用其他子系统时，我们并不关心如果找到其他子系统，我们只找数据总线，数据总线再根据统一标准找其他子系统，所以数据总线在这里充当一个只路人的作用。

数据总线是什么？后面会写一篇单独的文章！

优点：

1）降低用户成本
用户不需要关心各服务之间是什么语言的、不需要知道如果调用他们，只要通过统一标准找数据总线就可以了。
2）程序之间关系服务简单
3）容易识别哪些程序有问题（挂掉）

缺点：
1）提示了系统的复杂程度，性能有相应影响。
2）采用soap协议实现通讯，xml传输非常重，效率比较低。
3）服务化管理和治理设施不够完善。
4）依赖与中心服务发现机制。
5）不适用于前后端分离架构模式（xml，解析麻烦）

5、微服务架构

微服务架构是继SOA之后更加低耦合的一种架构，就目前而言，对于微服务，业界没有统一的定义，标准的定义。但通常而言，微服务架构是一种架构模式，或者说是一种架构风格，它提倡将单一的应用程序划分为一组小的服务，每一个服务运作在自己的进程内，服务之间相互调用，相互配置，为用户提供最终价值。服务之间采用轻量级的通信机制相互沟通，每个服务围绕着具体的业务进行构建并且能够被独立部署到生产环境中，另外，应尽量避免统一的，集中式的服务管理机制，对具体的一个服务而言，应根据业务业务上下文，选择合适的语言，工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写，也可以使用不同的数据存储。

技术维度进行理解：微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地的去解耦，每一个微服务提供单个业务功能的服务，一个服务做一件事情，从技术角度看就是一种小而独立的处理过程，类似进程的概念，能够自行单独启动和销毁，拥有自己的独立的数据库。

微服务强调的是服务的大小，他关注的是某一个点，是具体解决某一个问题。提供落地对应用服务的一和服务应用，狭义的看，可以看做是IDEA中的一个个微服务工程，或者Moudel。

微服务架构图：

优点：

1）每个服务足够内聚，足够小，代码容易理解，这样能聚焦一个指定的业务功能或者业务需求。
2）开发简单，开发效率高，一和服务可能就是专一的只干一件事情。
3）微服务能沟被小的团队单独开发，这个小团队是2—5人的开发人员组成。
4）微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或者部署阶段都是独立的。
5）微服务能使用不同的语言进行开发。
6）易于与第三方继承，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如：jenkins、Hudon、bamboo等。
7）微服务易于被开发人员理解修改个维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
8）微服务允许你利用融合最新技术。
9）微服务知识业务逻辑代码，不会和Html、Css或者其他界面混合。
10）每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库。

缺点：

1）开发人员要处理分布式系统的复杂性。
2）多服务运维难度，随着服务的增加，运维的压力也在增大
3）系统部署依赖
4）服务间通信成本高