初识微服务架构

去年买了《微服务架构设计模式》，断断续续看了几章。很多内容的理解浮于表面，影响不深。最近论文写完腾出一些空闲时间，遂欲系统地重读本书。目前读完了第一章，颇有受益，对微服务形成了宏观的认识。

一、微服务的产生原因

新事物的出现多半是旧事物无法满足现实需求，微服务也不例外。在微服务架构出现之前，常见的web应用都是以单体的形式进行开发部署。一个单体应用在项目开发的初期，具有设计简单、开发敏捷、测试部署方便等优点。但随着业务的发展，这个单体项目的代码与业务逻辑不断膨胀，就会陷入“单体地狱”。且单体地狱的出现只能被延缓，不可避免。

何为“单体地狱”？即一个单体应用随着承载业务逐渐增多，代码量不断膨胀，出现开发效率降低，代码逻辑复杂且相互制约，测试部署难度增大等问题。它通常具有以下特点：

1）代码复杂度高。系统本身过于复杂与庞大，团队新人难以理解代码逻辑，上手难度大。即使是团队老人，开发新需求时，也会碰到新代码受到旧代码的制约，开发完成后，测试容易出错等问题。

2）开发效率低下。庞大的项目体积导致IDE运行速度变慢，为了测试构建项目时间变得很长，严重拖慢了开发进度。

3）部署周期变长，且易出错。代码在开发完成后，需要进行测试与部署。一来，测试点数量庞大，完整进行测试的时间周期长。二来，由于系统的复杂度，新的改动常常“牵一发而动全身”，破坏了旧代码的约束与逻辑，出现意想不到的错误。诊断和修复问题也十分困难。

4）技术升级困难。在单体应用上尝试新技术是非常困难的。如一个Java单体项目不可能该用golang，除非重写整个项目。某个jar包A依赖低版本的jar包B，导致jar包B无法版本升级。

二、什么是微服务

针对单体应用的问题，便逐渐演化出了微服务这种解决方式。微服务将一个单体应用按照功能模块进行服务拆分，每个服务拥有自身单独的数据库，并可独立开发、测试、部署，并通过松耦合的方式进行进程通信。以书中的FTGO项目为例，这是一个类似于美团外卖的应用系统，包括餐厅管理、订单管理、配送管理、账单管理、支付管理等五大模块。那么根据微服务的架构思想，FTGO可将上述五大模块实现成五个独立的服务，分别由不同的团队进行负责管理。

采用上述微服务的架构模式，会带来以下好处：

1）开发效率提高。庞大的单体应用被“化整为零”，每个服务的体积远小于原来的大系统。一来，代码的复杂性会相应地降低，项目更易于理解。二来，每个团队可独立开发、测试、部署、维护组内的服务。三来，IDE的运行速度与项目的构建速度大幅提升，减少开发人员等待的时间。

2）每个服务可以独立扩展。如订单服务可以根据自身情况，部署更多机器，而餐馆服务则不作更改。

3）更容易实现技术升级。开发一个新服务时，完全可以使用不同的编程语言，只要根据约定好的通信方式暴露接口，屏蔽系统内部发生的变更即可。

三、微服务架构的弊端

Fred Brooks曾在《人月神话》中说到“软件工程没有银弹”。微服务架构也未能幸免，它在解决“单体地狱”的种种问题时，也会产生新的问题。

1）服务的定义与拆分具有挑战。微服务架构本身很优秀，但是能运用好则是一个严峻的挑战。由于服务的定义与拆分并没有一个完美的算法可以解决，这更多取决于架构师的水平。比起编程工作，这更像是一门艺术。糟糕的微服务拆分，会导致不同服务相互耦合，非但不能解决“单体地狱”的问题，还引入更多分布式服务的新问题。

2）分布式系统的复杂性。当一个单体应用采用微服务架构重写后，就成了一个分布式系统。而分布式系统会带来一系列新问题，包括进程间通信、分布式事务、数据一致性、自动化部署等。

3）各团队之间需谨慎协调。当一个需求需要更改多个服务时，需要多个团队协商确定方案，共同开发，并在发布时，确定一个发布计划，保证项目以正确的顺序进行发布。

四、软件工程没有银弹

目前市面上常出现的现象是，一个新技术的出现，会产生一批“无脑吹”。每一项新技术在解决旧问题的同时，也大概率会产生新的限制与弊端。但是狂热的追捧者常常是对优点大肆宣扬，对缺点却闭目不见、充耳不闻。殊不知，要充分发挥一项技术的力量，就必须辩证性地全面看待技术的正反两面。
微服务与单体，各有各的优势，也就有各自适合的场景。微服务是单体在逐渐走向复杂后的解决方案，但不是所有项目开发的唯一的答案。如果你的项目结构简单，且发展有限，那么杀鸡焉用牛刀，采用单体即可。毕竟使用微服务就不得不考虑包括服务拆分、分布式事务、数据一致性等复杂的问题。

五、否定之否定–微服务架构设计模式

本书第一章的最后，便是讨论过微服务的弊端之后，再对这些弊端进行一次否定。作者总结了采用微服务架构会碰上的各种困难与挑战，并将解决方案提炼成了一个个设计模式，详述将在后续篇章中徐徐展开。