1.1.4 微服务架构

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

微服务就是这样一种解决方案，从名字上来看，面向服务（SOA）和微服务本质上都是服务化思想的一种体现。如果SOA是面向服务开发思想的雏形，那么微服务就是针对可重用业务服务的更进一步优化，我们可以把SOA看成微服务的超集，也就是多个微服务可以组成一个SOA服务。伴随着服务粒度的细化，会导致原本10个服务可能拆分成了100个微服务，一旦服务规模扩大就意味着服务的构建、发布、运维的复杂度也会成倍增加，所以实施微服务的前提是软件交付链路及基础设施的成熟化。因此微服务在我看来并不是一个新的概念，它本质上是服务化思想的最佳实践方向。

由于SOA和微服务两者的关注点不一样，造成了这两者有非常大的区别：

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

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

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

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

图1-4 微服务架构