什么是微服务架构

概念

就目前而言，对于微服务业界并没有一个统一的，标准的定义。但通常而言，微服务架构的系统是一个分布式的系统，按业务进行划分为独立的服务单元，解决单体系统的不足，同时也满足越来越复杂的业务需求。换句话说，微服务提倡将单一应用程序划分一组小的服务，每个服务运行在其独立的自己的进程中，服务之间相互协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于RPC或HTTP 的 REST方式），每个服务都围绕着具体的业务进行构建，并且能够被独立的构建在生产环境、类生产环境等。另外，应避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。

那还是没有说清楚为什么要使用微服务，我们首先来看下系统框架。系统框架一般分为三种，分别是单体架构、集群架构和微服务架构。如果要了解微服务架构的优势，肯定就要先知道其他架构的缺点是什么，下面我们分别来看一下：

单机架构

在软件设计的时候经常提到和使用经典的3层模型，即表现层，业务逻辑层，数据访问层。虽然在软件设计中划分了3层模型，但是对业务场景没有划分，一个典型的单体架构就是将所有的业务场景的表现层，业务逻辑层，数据访问层放在一个工程中最终经过编译，打包，部署在一台服务器上。此时服务架构如图：

集群架构

单机架构，很常见，比如有一个很小的系统，不用处理很多东西，只需要一台服务器，在上面搭建出自己需要的服务，就可以开始工作。在小型应用的初期，访问量小的时候单机架构的性价比还是比较高的，开发速度快，成本低，但是随着业务的发展，逻辑越来越复杂，代码量越来越大，代码得可读性和可维护性越来越低。用户的增加，访问量越来越多单机架构的应用并发能力十分有限。可能会有人想到将单体应用进行集群部署，并增加负载均衡服务器，再来个缓存服务器和文件服务器，数据库再搞个读写分离。这就是集群架构。架构如图：

简单来说，集群架构就是把单机架构上面运行的服务，摘出来，然后复制，在多个服务器上面进行部署，这样可以提高工作效率。在集群中，每个服务器都称为节点，每个节点提供不同的服务，比如Database、Web、日志工具。

集群搭建出来后，有这样一个角色，负责调度客户端来的请求究竟要到哪一台服务器上去，然后在进行接下来的工作流，这个角色叫做——“负载均衡器”

集群也分为高可用集群，负载均衡集群（可能高并发架构就是负载均衡架构的升级版）。

高可用集群工具常见的有：heartbeat，pacemaker，keepalived

负载均衡器工具常见的有：nginx，lvs，HAproxy

集群架构优点：可扩展性，服务器资源不够用，就可以加一台继续进行工作

缺点：维护起来困难，trouble shoot的时候需要花费时间较多。

从单机结构到集群结构，你的代码基本无需要作任何修改，你要做的仅仅是多部署几台服务器，每台服务器上运行相同的代码就行了。但是，当你要从集群结构演进到微服务结构的时候，之前的那套代码就需要发生较大的改动了。

如果说单机架构基本不适合现实开发场景，那集群架构还是有其存在的意义，意义究竟是什么呢？

适用于中小型创业公司项目架构，小型技术团队快速迭代版本发布部署需求，前期低成本运行，爆发时可通过投入适量成本横向扩容服务器抗压。

特点：

• 前期技术开发成本低
• 一定的服务器扩容成本
• 核心团队编制及技能要求较少
• 项目发布部署基本无依赖，时间成本低
• 服务器运维成本一般
• 大而全的项目模块分离设计
• 更省更稳的技术架构选择
• 微服务架构强迫症不适用

微服务架构

了解了集群架构的优点和缺点，就大概知道了微服务架构的特点了：适用于业务架构较大的中大型科技公司项目架构，系统可拆分多个项目单独运营，大型技术团队、平台产品规范化管理，前期投入一定的成本，可以低成本扩容指定服务的服务器抗压。

特点： 

• 前期一定的技术开发成本
• 较低的服务器扩容成本
• 核心团队编制及技能要求较高
• 项目发布部署存在依赖，逐个部署，时间成本较高
• 服务器运维成本一般或较高
• 较清晰的项目模块分离设计
• 更潮更时尚的技术架构选择

举个例子，假设需要开发一个在线商城。按照微服务的思想，我们需要按照功能模块拆分成多个独立的服务，如：用户服务、产品服务、订单服务、后台管理服务、数据分析服务等等。这一个个服务都是一个个独立的项目，可以独立运行。

这样的好处有很多：

1. 系统之间的耦合度大大降低，可以独立开发、独立部署、独立测试，系统与系统之间的边界非常明确，排错也变得相当容易，开发效率大大提升。
2. 系统之间的耦合度降低，从而系统更易于扩展。我们可以针对性地扩展某些服务。假设这个商城要搞一次大促，下单量可能会大大提升，因此我们可以针对性地提升订单系统、产品系统的节点数量，而对于后台管理系统、数据分析系统而言，节点数量维持原有水平即可。
3. 服务的复用性更高。比如，当我们将用户系统作为单独的服务后，该公司所有的产品都可以使用该系统作为用户系统，无需重复开发。

综上，我们对于集群架构和微服务架构做了简单的场景分析，并不是说什么场景下一定要用什么架构，也不是说什么最潮流就用什么架构，而是根据实际成本和产出作为出发点做选择。

创业公司刚起步，资金可能也就百来万，搞微服务架构，光技术团队和服务器一个月的成本就占了公司一大头，产品还没上线，公司就已经倒闭了；

有资源的公司，动不动就能获得千万级甚至更高级别的融资，业务方向众多，若还只是用高可用架构，所有的业务模块都臃肿在一个项目里，不论是代码管理还是人员管理上，都是巨大的资源消耗。

搞清楚集群架构和微服务架构的简单区别后，既然本文是学习微服务的，下面就对微服务进行一个详细的介绍：

微服务将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在微服务结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC或HTTP 的 REST方式通信。

RPC（Remote Procedure Call Procotol）远程过程调用协议，通俗的解释就是：客户端在不知道调用细节的情况下，调用存在于远程计算机上的某个对象，就像调用本地应用程序中的对象一样。阿里巴巴的Dubbo框架，就是运用RPC协议比较好的框架。当采用微服务结构后，一个完整的系统可能有很多独立的子系统组成，当业务量渐渐发展起来之后，而这些子系统之间的关系将错综复杂，而且为了能够针对性地增加某些服务的处理能力，某些服务的背后可能是一个集群模式，由多个节点构成，这无疑大大增加了运维的难度。微服务的想法好是好，但开发、运维的复杂度实在是太高。为了解决这些问题，阿里巴巴的Dubbo就横空出世了。Dubbo是一套微服务系统的协调者，在它这套体系中，一共有三种角色，分别是：服务提供者（下面简称提供者）、服务消费者（下面简称消费者）、注册中心。你在使用的时候需要将Dubbo的jar包引入到你的项目中，也就是每个服务都要引入Dubbo的jar包。然后当这些服务初始化的时候，Dubbo就会将当前系统需要发布的服务、以及当前系统的IP和端口号发送给注册中心，注册中心便会将其记录下来。这就是服务发布的过程。与此同时，也是在系统初始化的时候，Dubbo还会扫描一下当前系统所需要引用的服务，然后向注册中心请求这些服务所在的IP和端口号。接下来系统就可以正常运行了。当系统A需要调用系统B的服务的时候，A就会与B建立起一条RPC信道，然后再调用B系统上相应的服务。这，就是Dubbo的作用。

REST，即Representational State Transfer的缩写。翻译过来是表现层状态转换。如果一个架构符合REST原则，就称它为RESTful架构。Spring Cloud框架，就是典型使用REST方式通信的。Spring Cloud是一个基于Spring Boot实现的云原生应用开发工具，它为基于JVM的云原生应用开发中涉及的配置管理、服务发现、熔断器、智能路由、微代理、控制总线、分布式会话和集群状态管理等操作提供了一种简单的开发方式。

SpringCloud 和 Dubbo 有哪些区别

最大区别：SpringCloud 抛弃了 Dubbo 的 RPC 通信，采用的是基于 HTTP 的 REST 方式。总体来说，两者各有优势。REST 相比 RPC 更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的依赖，这在强调快速演化的微服务环境下，显得更加合适。品牌机与组装机的区别：很明显 SpringCloud 比 Dubbo 的功能更强大，覆盖面更广，而且能够与 SpringFramework、SpringBoot、SpringData、SpringBatch 等其他 Spring 项目完美融合，这些对于微服务至关重要。使用 Dubbo 构建的微服务架构就像组装电脑、各环节我们选择自由度高，但是最终可能会因为内存质量而影响整体，但对于高手这也就不是问题。而SpringCloud 就像品牌机，在 Spring Source 的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性。在面临微服务基础框架选型时Dubbo与SpringCloud只能二选一。（这里只做大概对比）

现在我们知道微服务是将系统按业务进行划分为独立的服务单元，那究竟怎么划分呢？这里通过调研相关大佬的博客，可以从三种层面进行考虑，下面我们具体来看一下：

微服务拆分姿势

1.姿势一：

　新浪微博微服务专家胡忠想从纵横两个维度来划分，简单粗暴：

1.1 纵向拆分

　　从业务维度进行拆分。标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分为一个微服务。

1.2 横向拆分

　　从公共且独立功能维度拆分。标准是按照是否有公共的被多个其他服务调用，且依赖的资源独立不与其他业务耦合。

　　纵向以业务为基准，关系铁的在一起；横向功能独立的在一起。我想如果拆分这么简单，你有底气拆，敢拆吗？所以我们又继续比对一下其他专家的言论。

                                                

 

2.姿势二：

　　阿里的小伙伴从综合的维度来看，部分维度和上面会有重合。

2.1 服务拆分要迎合业务的需要

　　充分考虑业务独立性和专业性，避免以团队来定义服务边界，从而出现“土匪”抢地盘，影响团队信任。

　　这个维度和上面的类似，但是强调的是业务和团队成员的各自独立性，对上面是一种很好的补充。

2.2 拆分后的维护成本要低于拆分前

　　这里的维护成本包括：人力、物力、时间。

　　这里的成本对大部分中小团队来说都是必须要考虑的重要环节，如果投入和收益不能成正比，或者超出领导的预算或者市场窗口，那么先进的技术就是绊脚石，千万不要迷恋技术，所谓工程师思维千万要不得。

2.3 拆分不仅仅是架构的调整，组织结构上也要做相应的适应性优化

　　确保拆分后的服务由相对独立的团队负责维护。

　　这句话怎么理解呢？传统的团队划分是按照产品部、前端、后端横向划分，微服务化以后的团队可能就会是吃一张披萨饼的人数，产品、前端、后端被归类到服务里面，以服务为中心来分配人数。

2.4 拆分最有价值的结果是提高了系统的可扩展性

　　把具有不同扩展性要求的服务拆分出来，分别进行部署，降低成本，提高效率。比如全文搜索服务。

　　这点和上面的按功能独立性来拆分有点类似，功能独立其实就是面向可扩展性。

2.5 考虑软件发布频率

　　比如把20%经常变动的部分进行抽离，80%不经常变动的单独部署和管理。说白了就是按照8/2原则进行拆分。这个拆分的好处很明显，可以尽可能的减少发布产生的后遗症，比如用户体验、服务相互干扰等。

　　但是这里有一个问题，假如20%的服务分属于不同的业务层面，那该怎么办？所以这里的拆分应该有个优先级，在拆分相互冲突的时候应该要优先考虑权重比较高的那个。

                                                            

 

3.姿势三：

　　资深技术专家李运 华在他的架构书中给出的拆分：

3.1 基于业务逻辑

　　将系统中的业务按照职责范围进行识别，职责相同的划分为一个单独的服务。这种业务优先的方式在前面两种姿势当中都出现过，可见是最基本，最重要的划分方式（没有之一）。

3.2 基于稳定性

　　将系统中的业务模块按照稳定性进行排序。稳定的、不经常修改的划分一块；将不稳定的，经常修改的划分为一个独立服务。比如日志服务、监控服务都是相对稳定的服务，可以归到一起。这个很类似上面提到的2/8原则，80%的业务是稳定的。

　　至此你会发现服务的拆分真的没有绝对的标准，只有合理才是标准。

3.3 基于可靠性

　　同样，将系统中的业务模块按照可靠性进行排序。对可靠性要求比较高的核心模块归在一起，对可靠性要求不高的非核心模块归在一块。

　　这种拆分的高明可以很好的规避因为一颗老鼠屎坏了一锅粥的单体弊端，同时将来要做高可用方案也能很好的节省机器或带宽的成本。

3.4 基于高性能

　　同上，将系统中的业务模块按照对性能的要求进行优先级排序。把对性能要求较高的模块独立成一个服务，对性能要求不高的放在一起。比如全文搜索，商品查询和分类，秒杀就属于高性能的核心模块。

                                                        

 

4.姿势盘点：

　　以上不同拆分姿势各有千秋，异曲同工！

• 对业务逻辑均不约而同的放在第一位。

• 对业务模块的稳定性和可靠性，对功能的独立性、可扩展性都有相似的看法

• 强调拆分应该是多选，而不是单选。具体情况具体分析，可以自由灵活排列组合。

题外话

　　如果你把上面的划分角度背下来了拿去现场套，可能还会遇到矛盾或争议。

1.业务矛盾：

　　假如我们按照业务来划分，根据粒度大小，可能存在以下两种：

• 第一种分为商品、交易、用户3个服务；
• 第二种分为商品、订单、支付、物流、买家、卖家6个服务。

　　3 VS 6，这该怎么办？

　　如果你的团队只有9个人，那么分成3个是合理的，如果有18个人，那么6个服务是合理的。这里引入团队成员进行协助拆分。

　　可见拆分的姿势不是单选，而是多选的。这个时候必须要考虑团队成员数量。

　　在拆分遇到争议的时候，一般情况下我们增加一项拆分条件，虽然不是充要条件，但至少我们的答案会更加接近真理。

　　除了业务可能存在争议，其他的划分也会有争议，比如一个独立的服务到底需要多少人员的配置？

2.三个火枪手(人员配置)

　　上面提到的人员数量配置，这里为什么是9和18呢？(这里的团队配置参考李云华前辈提到的三个火枪手的观点)

　　换一种问法，为什么说是三个人分配一个服务（当然，成员主要是后端人员）？

• 假设是1个人，请个假、生个病都不行。一个人会遇到单点的问题，所以不合理。
• 假设是2个人，终于有备份了，但是抽离一个后，剩下1个压力还是很大，不合理。
• 假设是3个人，抽离一个还有2个在。而且数字3是个稳定而神奇数字，用得好事半功倍。特别是遇到技术讨论，3个人相对周全，如果是2个可能会各持己见，带有自我的偏见和盲区。

　　那么这个3是不是就是稳定的数量呢？

　　假设你做的是边开飞机边换引擎的重写工作，那么前期3个人都可能捉襟见肘。但是到了服务后期，你可能1个就够了。

　　所以3在我的理解应该是一个基准线，不同的时间段会有上下波动，但是相对稳定。

 

 

 

 

 

参考文献：

Java高可用集群架构与微服务架构简单分析

Java面试——微服务

什么是微服务

集群和微服务到底是什么？

微服务划分的姿势