应用开发将回归单纯时代

以前，我们的大部分应用都是单体应用，这些应用都是跑在一台电脑上的，不需要分布式协作。就像 MySQL 这样的中间件，刚开始也是为单机设计的，没有考虑到分布式。而现在，随着应用规模不断扩大的需求，底层基础设施也在不断地扩展，云计算就是最好的例子，它将底层基础设施抽象成资源池，再提供给用户，用户不需要知道底下的物理服务器是怎样组成的。

底层基础设施的分布式结构，导致了应用层也需要考虑到分布式，比如目前流行的微服务架构，需要考虑远程调用。有了远程调用，就需要考虑到各种异常情况，比如超时，然后就需要各种应对机制，比如限流、熔断、降级等。所以，底层基础设施组成方式这样的变化，导致应用开发者需求去了解以前不必考虑的东西，应用开发就变得越来越复杂。

服务网格(Service Mesh)的出现，为微服务应用的开发带来了一些简化，其思想就是把一些通用的机制以Sidecar(边车)的形式部署到应用服务所在的服务器，远程调用都需要经过Sidecar，然后才能到应用服务，这样应用服务只需要处理真正的业务逻辑，而不需要考虑限流、熔断等机制。下面是这种架构的示意图：

在上图中，Instance是我们应用服务，Sidecar是一些通用的机制，随着基础环境的建立而部署，也就是把Instance里面原来需要考虑的内容，下放到了Sidecar，于是两者可以独立部署维护。这种方式就类似于在TCP/IP协议出现之前，如果你要写网络应用程序，你需要自己去保证数据包的顺序、重传等底层机制，要编写一个正确的网络应用变得非常困难，TCP/IP协议出现后，这些重复性的脏活累活交给了操作系统的内置模块来完成，大大减轻了应用开发者的负担。

自从有软件开发这个职业以来，各种应用开发框架层出不穷，它们都有一个共同的目的，就是让应用开发者能更轻松的开发应用，只不过目前市面上的开发框架过多，也造成了很多开发者疲于跟进的现象。云计算先是做IAAS层，然后到PAAS层，PAAS层是针对开发者的，那么很多大厂也都想方设法把PAAS层做好，这样就可以绑定开发者。因此，目前的网格服务也好，无服务架构也好，都是云计算大厂大力投入的方向。这些大厂都会把他们能做的都做了，也就是将原本由开发者负责考虑的各种功能机制下沉到他们的基础设施层面，让开发者开发应用越来越简单。谁能下沉的东西更多，对开发者更友好，可能就会吸引更多的用户。这样竞争的结果是，应用开发越来越简单，以后应用开发者可能不需要考虑底层是分布式的系统，因为底层看起来就是一台电脑，分布式服务间调用就像单体应用时代进程间调用，这样开发分布式应用时也像以前开发单体应用那样变得更简单。从这些层面来看的话，恐怕应用开发将回归单纯时代了。

微信扫码，进入【技术人成长】社群逛逛。