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

1.1.1 单体架构

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

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

1.1.2 集群和垂直化

1.1.3 SOA

核⼼⽬标是把⼀些通⽤的、会被多个上层服务调⽤的共享业务提取成独⽴的基础服务。这些被提取出来的共 享服务相对来说⽐较独⽴，并且可以重⽤。所以在SOA中，服务是最核⼼的抽象⼿段，业务被划分为⼀ 些粗粒度的业务服务和业务流程。

SOA主要解决的问题是： 信息孤岛和共享业务的重⽤。

 1.1.4 微服务架构

业务系统实施服务化改造之后，原本共享的业务被拆分形成可复⽤的服务，可以在最⼤程度上避免 共享业务的重复建设、资源连接瓶颈瓶颈等问题。那么被拆分出来的服务是否也需要以业务功能为维度 来进⾏拆分和独⽴部署，以降低业务的耦合及提升容错性呢？

微服务就是这样⼀种解决⽅案，从名字上来看，⾯向服务（SOA）和微服务本质上都是服务化思想 的⼀种体现。如果SOA是⾯向服务开发的思想的雏形，那么微服务就是针对可重⽤业务服务的更进⼀步 优化，我们可以把SOA看成微服务的超集，⼀但服务规模扩⼤就意味着服务的构建、发布、运维的复杂 度也会成倍增加，所以实施微服务的前提是软件交付链路及基础设施的成熟化。因此微服务在我看来并 不是⼀个新的概念，他本质上是服务化思想的最佳实践⽅向。由于SOA和微服务两者的关注点不⼀样， 造成了这两者有⾮常⼤的区别：

SOA关注的是服务的重⽤性及解决信息孤岛问题。

微服务关注的是解耦，虽然解耦和可重⽤性从特定的⻆度来看是⼀样的，但本质上是有区别的，解 耦是降低业务之间的耦合度，⽽重⽤性关注的是服务的复⽤。

微服务会更多地关注在DevOps的持续交付上，因为服务粒度细化之后使得开发运维变得更加重要， 因此微服务与容器化技术的结合更加紧密。

如图所示，将每个具体的业务服务构成可独⽴运⾏的微服务，每个微服务只关注某个特定的功能， 服务之间采⽤轻量级通信机制REST API进⾏通信。细⼼的读者会发现SOA中的服务和微服务架构中的 服务粒度是⼀样的，不是说SOA是微服务的超集吗？其实我们可以把⽤户服务拆分的更细，⽐如⽤户注 册服务、⽤户鉴权服务等。实际上，微服务到底要拆分到多⼤的粒度没有统⼀的标准，更多的时候是需 要在粒度和团队之间找平衡的，微服务的粒度越⼩，服务独⽴性带来的好处就越多，但是管理⼤量的微 服务也会越复杂。