常见的服务架构演变

背景

在互联网的发展中，后端的web服务也经历了很多的演变；在公司业务稍微简单的时候，采用简单的服务，可以提高开发效率，可以帮忙节省更多的成本。但随着用户数量的剧增，流量突增；业务越来越复杂，简单的服务也来不满足公司的发展。接下来就简单列一下服务架构。

单体服务

在很多的小公司，或者业务简单的公司，这种服务依旧是主流。这种服务就是将所有的业务代码，全都写在一个项目中，就像我们打包的一个jar。当然为了服务有更好的性能，我们的服务不会只布在一台服务器上，如下图所示。

当我们在终端访问服务的时候，会经过一个路由算法，比如nginx的反向代理，通过负载均衡算法，可以将终端的请求转发到其中的一个web服务中。因此这样的架构也有优点：

• 高可用，我们可以部署多个服务器；
• 简单，所有的功能都可以在一个服务器上处理，只需配置一下转发即可；
• 性能也较好，所有服务器上都可以处理所有的业务逻辑，并且没有后端之间的远程调用。

以上的方式非常的简单，当把代码开发完成后，提交的远程的仓库，然后使用jenkins这种方式进行打包，使用脚本启动服务。但是当随着业务逻辑越来越多，越来越耦合，如果这是时候出现了代码bug，就会导致整个服务不可用，或者任务阻塞，导致服务器没有资源去做其他的事情。并且随着代码越来越多，代码的维护也越来越复杂，改了某个地方会导致其他业务不能用。因此，在这样一个背景下，怎样去搭建一个低耦合，高内聚的服务呢？

单节点微服务

在互联网很多的企业，已经采用了一种分布式架构的方式，其中的微服务就使用的很成功、很广泛。这种架构通过将原有的整个服务进行划分，将不同的业务划分成不同的模块，然后模块之间使用rpc进行访问。如下图所示：

该图中就是一个简单的物联网设备的控制服务，将定时服务和控制服务拆分出来，形成一个独立运行的服务，而服务之间通过rpc之间进行调用。通过这样划分，可以实现以下的优点：

• 灵活性得到更大的提高，比如相应的设备逻辑，我改相应的服务，而不会影响定时，设备控制等服务。
• 业务的独立性得到增强，开发的难点得到了降低。

但是也有缺点，在微服务中，服务之间采用了远程调用rpc，所以性能有所下降；各个服务之间交互，各自会维护自己的数据库，在相互通信的过程中，数据的一致性难以保证。

混合服务

通过借鉴，单体服务的思想，现在很多的公司采用的一种混合切分一种方式，提高系统可用性，防止因为一个节点的崩溃导致服务不可用。

如上图所示，在每个单独的服务，增加了像单体服务那样的路由算法，形成集群，提高了系统的可用性和稳定性。

结语

以上就是简单的梳理，在分布式架构中还有CAP原则，BASE理论。在这些理论中，主要强调，可用、性能、一致性的取舍。为了满足用户的良好体验，我们在设备的过程中，需要跟多地满足可用和性能两个要素，其中的数据一致性，我们更多地采用一种软一致性，通过一种时间换空间的方式来保证数据的一致性。