微服务简介

1.1 从单体架构到微服务架构的演进

---

前言

本章从架构发展的⻆度来描述技术的发展过程，根据不同阶段所⾯临的问题来推动架构的演变，从
⽽更好地理解微服务的本质以及它所带来的的好处，本章内容主要会通过架构的演进过程帮助⼤家建⽴
⼀个整体意识，从⽽更好地掌握微服务体系。

---

1.1、从单体架构到微服务架构的演进？

1.1.1 单体架构

我们开发⼀个⼀个Web项⽬，可以使⽤Spring、SpringMVC、Mybatis等技 术。⽐如之前的快递驿站项⽬，旅游⽹项⽬SSM版，账单管理项⽬等，项⽬结构如下图1-1所示。

整个系统的架构⾮常简单，使⽤Spring+SpringMVC+Mybatis构建⼀个基础⼯程、MySQL数据库

作为持久化存储，在这个⼯程中创建不同的Service实现项⽬中不同的业务场景，如线路、线路分类、⽤户等。最后把项⽬构建成⼀个war包部署在Tomcat容器上即可使⽤，这时我们之前经常采⽤的架构。
通常来说，如果⼀个war包或者jar包⾥⾯包含⼀个应⽤的所有功能，则我们称这种架构为单体架
构。
很多传统互联⽹公司或者创业型公司早期基本都会采⽤这样的架构，因为这样的架构⾜够简单，能
够快速开发和上线。⽽且对于项⽬初期⽤户量不⼤的情况，这样的架构⾜以⽀撑业务的正常运⾏。

1.1.2 集群和垂直化

以商城系统为例。随着业务的发展，产品被越来越多的⼈使⽤，那么对于整个技术架构来说，可能
会⾯临以下挑战：

• ⽤户量越来越⼤，⽹络访问量不断增⼤，导致后端服务器的负载越来越⾼。
• ⽤户量⼤了，产品需要满⾜不同⽤户的需求来留住⽤户，使得业务场景越来越多并且越来越复杂。
• 当服务器的负载越来越⾼的时候，如果不进⾏任何处理，⽤户在⽹站上操作的响应会越来越慢，甚
  ⾄出现⽆法访问的情况，对于⾮常注重⽤户体验的互联⽹产品来说，这是⽆法容忍的。
• 业务的场景越多越复杂，意味着war包中的代码量会持续上升，并且各个业务代码之间的耦合度也
  会越来越⾼，后期的代码维护和版本发布涉及的测试和上线，也会很困那。举个最简单的例⼦，当
  你需要在库存模块⾥⾯添加⼀个⽅法时，带来的影响是需要把整个系统重新测试和部署，⽽当⼀个
  war包有⼏GB的⼤⼩时，部署的过程也是相当痛苦的。

因此，我们可以从两个⽅⾯进⾏优化：

1. 通过横向增加服务器，把单台机器变成多台机器的集群。
2. 按照业务的垂直领域进⾏拆分，减少业务的耦合度，以及降低单个war包带来的伸缩性困难问题。
   如图1-2所示，我们把商城系统按照业务维度进⾏了垂直拆分：⽤户⼦系统、库存⼦系统、商品⼦系
   统，每个⼦系统由不同的业务团队负责维护并且独⽴部署。同时，我们针对Tomcat服务器进⾏了集群
   部署，也就是把多台Tomcat服务器通过⽹络进⾏连接组合，形成⼀个整体对外提供服务。这样做的好
   处是能够在改变应⽤本身的前提下，通过增加服务器来进⾏⽔平扩容从⽽提升整个系统的吞吐量。
   需要注意的是，图1-2中针对数据库进⾏了垂直分库，主要是考虑到Tomcat服务器能够承载的流量
   ⼤了之后，如果流量都传导到数据库上，会给数据库造成⽐较⼤的压⼒。
   总体来说，数据库层⾯的拆分思想和业务系统的拆分思想是⼀样的，都是采⽤分⽽治之的思想。
   

1.1.3 SOA

为了让⼤家更好地理解SOA，我们来看两个场景：

• 假设⼀个⽤户执⾏下单操作，系统的处理逻辑是先去库存⼦系统检杳商品的库存，只有在库存⾜够
  的情况下才会提交订单，那么这个检查库存的逻辑是放在订单⼦系统中还是库存⼦系统呢？在整个
  系统中，⼀定会存在⾮常多类似的共享业务的场景，这些业务场景的逻辑肯定会被重复创建，从⽽
  产⽣⾮常多冗余的业务代码，这些冗余代码的维护成本会随着时间的推移越来越⾼，能不能够把这 些共享业务逻辑抽离出来形成可重⽤的服务呢？

• 在⼀个集团公司下有很多⼦公司，每个⼦公司都有⾃⼰的业务模式和信息沉淀，各个⼦公司之间不
  进⾏交互和共享。这个时候每个⼦公司虽然能够创造⼀定的价值，但是由于各个⼦公司之间信息不
  是互联互通的，彼此之间形成了信息孤岛，使得价值⽆法最⼤化。
  基于这些问题，就引⼊了SOA （Service-Oriented Architecture ）,也就是⾯向服务的架构，从语
  义上说，它和⾯向过程、⾯向对象、⾯向组件的思想是⼀样的，都是⼀种软件组建及开发的⽅式。核⼼
  1.1.3 SOA
  ⽬标是把⼀些通⽤的、会被多个上层服务调⽤的共享业务提取成独⽴的基础服务。这些被提取出来的共享服务相对来说⽐较独⽴，并且可以重⽤。所以在SOA中，服务是最核⼼的抽象⼿段，业务被划分为⼀些粗粒度的业务服务和业务流程。
  如图1-3所示，提取出了⽤户服务、库存服务、商品服务等多个共享服务。在SOA中，会采⽤ESB
  （企业服务总线）来作为系统和服务之间的通信桥梁，ESB本身还提供服务地址的管理、不同系统之间
  的协议转化和数据格式转化等。调⽤端不需要关⼼⽬标服务的位置，从⽽使得服务之间的交互是动态
  的，这样做的好处是实现了服务的调⽤者和服务的提供者之间的⾼度解耦。总的来说，SOA主要解决的问题是：

• 信息孤岛。

• 共享业务的重⽤。

1.1.4 微服务架构

业务系统实施服务化改造之后，原本共享的业务被拆分形成可复⽤的服务，可以在最⼤程度上避免
共享业务的重复建设、资源连接瓶颈瓶颈等问题。那么被拆分出来的服务是否也需要以业务功能为维度来进⾏拆分和独⽴部署，以降低业务的耦合及提升容错性呢？
微服务就是这样⼀种解决⽅案，从名字上来看，⾯向服务（SOA）和微服务本质上都是服务化思想
的⼀种体现。如果SOA是⾯向服务开发的思想的雏形，那么微服务就是针对可重⽤业务服务的更进⼀步优化，我们可以把SOA看成微服务的超集，⼀但服务规模扩⼤就意味着服务的构建、发布、运维的复杂度也会成倍增加，所以实施微服务的前提是软件交付链路及基础设施的成熟化。因此微服务在我看来并不是⼀个新的概念，他本质上是服务化思想的最佳实践⽅向。由于SOA和微服务两者的关注点不⼀样，造成了这两者有⾮常⼤的区别：

• SOA关注的是服务的重⽤性及解决信息孤岛问题。
• 微服务关注的是解耦，虽然解耦和可重⽤性从特定的⻆度来看是⼀样的，但本质上是有区别的，解
  耦是降低业务之间的耦合度，⽽重⽤性关注的是服务的复⽤。
• 微服务会更多地关注在DevOps的持续交付上，因为服务粒度细化之后使得开发运维变得更加重要， 因此微服务与容器化技术的结合更加紧密。
  如图1-4所示，将每个具体的业务服务构成可独⽴运⾏的微服务，每个微服务只关注某个特定的功能，
  服务之间采⽤轻量级通信机制REST API进⾏通信。细⼼的读者会发现SOA中的服务和微服务架构中的
  服务粒度是⼀样的，不是说SOA是微服务的超集吗？其实我们可以把⽤户服务拆分的更细，⽐如⽤户注册服务、⽤户鉴权服务等。实际上，微服务到底要拆分到多⼤的粒度没有统⼀的标准，更多的时候是需要在粒度和团队之间找平衡的，微服务的粒度越⼩，服务独⽴性带来的好处就越多，但是管理⼤量的微服务也会越复杂。