从单体到微服务，这些年架构的演变

背景

这两年业界最流行的技术架构话题已经从前后端分离，变成了分布式、微服务、DDD了。微服务架构适合所有的公司吗，业务场景演变到了什么地步才需要考虑上微服务呢？毕竟选择技术架构之前应该考虑业务是否与之匹配，否则分布式、微服务这类繁重的架构设计对一些公司来说就变成了屠龙之技，反而成为一线开发团队的负担。

在我不长的职业生涯中，经历过小型创业公司、国企般的大型项目以及在ThoughtWorks见到的各种项目。架构就像一个杂货铺，微服务也只是工具箱，不能有了锤子满世界找钉子。

我想尝试让架构这个概念变得更为通俗，原谅我文中出现大量不恰当的比喻。为了描述常见互联网公司技术架构演变过程，这里设定了一个虚拟背景：

Neo是一名软件工程师，毕业后就留在这个城市加入了一家互联网创业公司，公司的业务是从事面向餐厅的食材配送服务，用户可以从APP或者微信提前订购食材，公司会在次日早晨送达。使用了Java + MySQL的技术栈，目前来说还只是使用了一台服务器，并且数据库和应用程序都还是部署在同一台服务器上。

因为用户增加和业务逐渐变得复杂，Neo的团队遇到的第一个问题就是需要对系统扩容，提高系统响应速度。扩容对于互联网公司来说一般就是“加机器”，那么第一步，怎么加机器呢？

单数据库多应用服务架构

增加机器方案的时候，我第一时间想到的是软件园餐厅的工作模式了。

软件系统用户就像来餐厅吃饭的顾客，而服务器就像服务员，本来服务员既可以收费也可以售卖菜品，就像有时我们在同一台服务器上同时部署了应用代码和数据库。如果在服务员同时承担结账和售饭职责的模式上增加人手的话，效率不高且最终的账目很可能无法保持一致，因此餐厅一般会有多个服务员售饭，然后由专人负责结账。

回到我们的架构问题上来，如果我们需要多台服务器响应更多的用户，同时也要保证数据的一致性。根据数据库的范式理论，数据的冗余性越低数据的一致性就越高。因此我们的第一步方案可以剥离为多个应用服务器处理用户的请求，一台数据库服务器来集中处理数据的读写，这样就能够达到分摊服务器压力的同时也能保证数据的正确。

不过在应用服务器的入口，我们需要增加一个负载均衡服务器，来分配不同的用户请求到特定的应用服务器上。这有点类似于餐厅的排队机，对用户分流。负载均衡服务器可以是普通PC服务器上配置Nginx一类的软件，也可以是F5这类专用的硬件负载均衡设备。