下一代软件架构【软件架构发展历程】【service mesh】

最近二十年，随着信息技术的飞速发展，互联网用户的爆发式增长，软件架构和软件开发模式也在不断变革。从单体应用到分布式应用，再到微服务，云原生，并从中衍生出了一系列软件生命周期概念，如devops，持续交付等。这点在一线大厂中应该会感触颇多，下面我们以java语言体系为基础，分阶段介绍下软件架构和软件开发流程的演进，以及未来软件架构的走向和发展。

单体架构时期

在互联网应用的早期，大多数都是采用的这种架构。项目所有代码打包在一个jar包中，并部署在价格昂贵的小型机上面。一个项目的服务器基本就只有一台小型机，数据库，应用都部署在上面。

由于当时互联网用户并不是很多，所以这套架构还是可以支撑日常使用的，但随着互联网用户的爆发式增长，一台小型机的资源已经不足以支撑一个项目的日常运行（当时想对小型机加资源还是比较困难的，并且对于早期的jdk版本来说，内存过大会造成性能降低，并不能一味加内存来支撑更多的业务），这时候人们开始探索分布式的部署。

早期分布式系统时期

由于一台机器的资源无法支撑业务了，所以各位工程师想出来一个办法，部署了两台机器来承担用户流量。这也就是集群的思想，用多台机器共同组成一个大的系统，这让当时的系统吞吐量有了极大的提升。

这在一定程度上缓解了用户流量的问题，只需要后端不断扩展机器即可。目前很多传统行业的软件架构还处在这个阶段。但是随着用户数量的继续上升和业务需求的不断繁杂，这个架构的问题也日益暴露出来：

1.用户流量的问题解决了，但是这套架构会造成资源的浪费。比如我的java应用有100个接口但是只有其中的10个接口使用频繁，我为了让这10个接口的流量平分到多个机器上，每个机器都部署了100个接口，实际上剩余的90个接口都不需要部署多份。这使得当时本就昂贵的硬件资源遭到了很大的浪费。

2.所有的项目部署，重启，迭代非常麻烦，系统耦合极高。比如我想做弟101个接口，我需要改动的是所有功能的代码。代码编写完成之后需要重新部署项目，由于所有功能都在一个jar包之中，项目打包，启动的过程都非常缓慢，且牵一发而动全身，一旦因为第101个接口的问题，导致项目启动失败，原来的100个接口也不可用。

基于以上的两点，系统架构有了新的探索，各个公司将原本的大系统进行了拆分，现代的分布式系统时期也就到来了。

现代分布式系统时期

这个时期的到来有两个前提：

1.软件自身耦合性过高，为了有更好的灵活性不得不拆，业界也对系统的拆分有了理论依据，比如康威定律。

2.虚拟化技术的成熟，可以让一台物理机器可以隔离出多个互不干扰的虚拟机，这解决了项目拆分后的部署问题。

在这两个前提下，各个公司纷纷开始了项目拆分的探索，现代分布式系统时期到来。早期的拆分基本遵顼的是康威定律，按照系统的组织架构对系统进行垂直的拆分。比如一个大的电商系统，会根据业务的维度拆分成订单，用户，商品等多个小系统，每个小系统独立部署。目前还有很多传统企业的架构处在这个阶段，此阶段的架构已经比较适合传统行业里的中型项目架构了（或者我认为是最适合的架构了，灵活性和扩展性得到保证，且不会过于复杂）

但是随着用户流量的进一步激增和项目规模的进一步增大，这个架构在拆分粒度上还是太大，有些公司往往需要在功能层面甚至接口层面进行拆分。一个大系统拆分成成百上千个小系统，对于拆分后的各个系统的管理也成为了一大难题。这就推动这系统架构有了一个新的质变，也就是目前所说的微服务架构。

微服务时代

  微服务最早由Martin Fowler与James Lewis于2014年共同提出。微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制（HTTP）。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。

在当时，云计算和容器化技术并没有成熟，这也就导致服务拆分的过细会导致资源分配不灵活，服务治理难度大。这让微服务的发展陷入了停滞。但随着docker和k8s的兴起，让大规模的服务治理有了解决方案，云计算的高速发展让资源分配有了解决方案。这两个技术的突破，推动了我们的系统架构的又一次革新。

微服务的概念，发展到现在，它已经不仅仅是一个思想了，它是思想和一系列解决方案的统称。在我看来，微服务概念包含如下几点：

1.服务的拆分

2.服务的治理

3.服务间的通信

服务的拆分

软件工程发展到今天，服务的拆分，已经有了非常多的理论依据，比如早期的康威定律，再到前两年比较火的DDD。

服务的治理

随着服务数量越拆越多，一个项目会出现成百上千个服务。这对服务的运维治理造成了极大的困难，但随着docker和k8s的成熟以及spring cloud的普及，我们有了完善的服务治理体系。

服务间的通信

由于微服务架构是将原来单体的项目拆分成了多个服务，所以服务和服务之间的通信成本增加了，如何让两个服务之间的接口调用变得像单体应用一样方便变得尤其重要。但是好在spring cloud中也为我们提供了多种远程调用解决方案，比如阿里的dubbo，netfilx的feign，以及可以跨语言的thrift。

以上的三点在我看来是微服务的核心，在这三点之外现代软件开发在微服务的大环境下又提出了很多概念，如：devops，持续交付，云原生等。这些概念来源于微服务的大环境，也可以将其作为微服务的核心概念。

devops

表面含义为：开发和运维，它是一种思想和工具的集合，它的思想要求开发和运维一体化，高度融合。为了实现这个思想，借助了一些列的工具来实现二者的融合，如cicd工具jenkins，日志监控工具elk等。

持续交付

这是来自敏捷开发的一个概念，它所表达的是软件发布需要做到可以实时发布且不消耗开发人员的精力，其也是概念和工具的集合。首先在敏捷场景中，项目要不断迭代，小步快跑。假如项目一天可以交付5次，难道开发人员要每天手动5次发版？这显然是不科学的，为此我们可以借助jenkins实现自动发版。

云原生

这是一个比较新的概念，随着云计算的不断深入，无论大公司还是小公司，其软件部署上云都是大趋势。如何构建出适应云环境的程序成了大家都在思考的问题。那怎么才算是适合云环境的程序？

首先我们知道云与传统物理环境的优势是弹性运算，动态扩展。让我们的资源调配更加细粒度，更加灵活。适应于云环境的程序当然是要程序本身可以支持弹性运算，动态资源扩展。

1.这与当前的容器化技术不谋而合，容器化技术可以支持应用的动态配置、统一管理等。

2.这与微服务也有着相关性，服务细粒度拆分，云计算可以支持为不同的服务设置不同的计算资源，灵活满足服务的需求

3.这也与当下的devops，持续交付，敏捷开发相通。

云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。

云原生最早由Pivotal的Matt Stine于2013年首次提出，他提到云原生定义目前不明确，但含义丰富。经过多年的发展，其定义被各个厂商和机构一次次更新至今没有确切的定义。因为云原生一直在发展变化之中，解释权不归某个人或组织所有。

综合看来，云原生的概念可以概括为以下四条：

DevOps、持续交付、微服务、容器

更加通俗的讲，云原生是为了构建更加符合云环境的程序，怎么才算是适合云环境的程序？那就是这个系统要包含devops、持续交付、微服务、容器。

针对于云原生，谷歌与Linux基金会一起创办了CNCF基金会（可以看成和apach一样的组织），专门孵化云原生技术，致力于云原生生态的构建。如已经孵化毕业的k8s，containerd，etcd等，还有孵化中的linkerd，gRPC，argo等。

下一代架构

微服务发展至今，也出现了一些需要解决的问题，我认为最主要的是为了将服务拆分的更加细粒度，导致系统复杂度上升，并且各种微服务解决方案百家争鸣，如果想构建出一个完善的微服务体系需要极高的技术储备，这点的制约让很多公司尤其是中小型创业公司望而却步。软件架构发展到今天的地步，系统的吞吐量和伸缩性的问题已经被解决好了，下一步的发展方向应该是如何将繁杂的系统简单化，如何以相对较低的技术水平快速开发出云原生的应用。

沿着这个思路，有一个概念浮出了水面！service mesh！它利用容器化技术，将复杂的容器治理，负载均衡等非业务且技术要求较高的东西全部封装。开发人员只需要注重业务代码即可。它目前也处在探索过程中。我认为大概率会成为下一个架构变革的关键性技术。

service mesh的思想是将原本应该由程序员关心的负载均衡，路由，网络等问题全部交给一个代理sidecar来管理，并且这个sidecar可以与容器相结合直接嵌入到容器中，让程序员在编写业务代码的时候对sidecar所作的事情无感知。这极大提升了业务程序员的coding效率。

警示

从技术的演变来看，最终追求的都是业务代码的快速，简单编写。这也就导致未来的程序员一定是朝着两极分化的方向发展的，业务代码的编写越加容易，门槛也会渐渐降低，导致业务程序员会越来越普遍。另一方面专注架构的程序员也会越来越少，因为已经有了比较完善的架构体系，且架构会越来越复杂，架构的准入条件越来越苛刻。

所以如果想从事程序员的话，必须保持技术敏感度，这样才不容易被时代淹没。