应用架构的演进趋势 | docker

type

Post

status

Published

date

Jan 16, 2023

slug

docker/history

1.1 传统分层架构 vs 微服务

1. 单体架构

在20年前，其实应用架构是非常简单的，那个时候基本上就是ASP、JSP，ASP可能很多人都都没听过。就JSP代码前后台逻辑在一起，那个时候只有业务逻辑。业务逻辑是嵌在页面上的，甚至有时候都是CS结构，然后后面加一个DB。

扩展阅读：PHP 与 JSP 比较（PHP、ASP、JSP是什么） - 腾讯云开发者社区

那个时候的网站或者是任何的应用都比较小。那么，这对于这种比较小的逻辑，不复杂的应用，我可以用一个项目去管理的。

但是大家知道，这么多年来，业务的复杂性可是指数级上升的。你想想像腾讯像阿里这样体量的应用，这样体量的公司，如果所整个网站都是一个单体架构，都是一份代码的话。那我这个网站得耗消耗多少资源？所以，这个架构演进是不断推进的。

退回到十几年前大家大家那个时候基本上所有的应用架构模式都是前端、业务逻辑层和数据库，那么也就是我们常说的分层架构。

在这种架构下，大部分业路业务逻辑，就是前端表现，业务逻辑数据访问这个分层很清晰。然后每家公司招人就是招前端，后端和DBA。然后大家写项目，写项目代码的时候往往就是前端的代码放一起，所有业务逻辑放一起，所有DBA在一起维护数据库。那么，当业务复杂到一定程度，这个应用其实是没有办法维护的。

举个例子，这是一个IBM项目的反例：微服务架构没有出现之前，在IBM有800多个人做一个产品，800多个人想想，那得投多少钱？做一个产品，这些这个产品基本上所有代码都一放在一起的，揉在一起的，到了最后没有一个人能清楚的知道什么代码是负责什么的；没有人知道我要做一个变更，我要做一个设计的变更，我要做一个refactor(重构)，会对系统有多大的影响。所以到最后这个系统就没法维护了，没人敢没人敢去动这个产品。什么时候发布？只有当产品经理或者项目经理说，哎，测试你们不要测了，我们下个月就要发布了，所以你们现在不要测了啊，这个时候唉bug数量下来了，大家就是装作没有问题一样，把这个产品release出去了。可是release出去代码能用吗？是不能用的，所以在这种架构下面一定是有这样的问题的。人的脑容量是有限的，没有人能够掌握全局，看清所有的业务逻辑，所以它就没有办法维护了。

2. 演进: SOA (面向服务的架构)、ESB(企业服务总线)

那这么复杂的业务应该怎么样去做呢？其实，随着业务复杂，这个架构的模式就在不断的演进。IBM之前推了SOA架构，就是service oriented architecture，那基本上是会把一个大的系统解偶。然后子系统和子系统之间通过网络调用去互相交互。然后SOA架构本身，它又提了一个概念，叫 ESB 企业服务总线，就是enterprise service bus。但是它倡导的一种理念是组件和组件之间的调用是要经由这个ESB的，ESB作为一个企业的集中的服务总线，所有的服务调用都是从它这儿走。那最后造成的一个问题就是ESB本身又变成一个单体架构了，它的这个升级和变更又变得不可维护了。

扩展阅读：什么是 SOA（面向服务的架构）？-IBM ; 什么是 ESB（企业服务总线）？-IBM

3. 微服务架构

所以SOA架构其实到后面也基本上就凉掉了，再演进再演进就到了我们现在所认可的，或者是现在流行的一种微服务架构。

微服务架构就是基于轻量级的网络调用，你可以把微服务理解成为是SOA的一种最佳实践。它讲究服务和服务之间是走轻量级协议的。

比如说REST，非常容易维护。他推崇的是微服务和微服务，就是把服务尽量打小打散，让不同的开发和业务部门去负责不同的子系统。比如说我A部门负责这两个子系统，B部门负责这三个子系统，那么这样的话就会有一批专业的人为这个整个业务的完整的生命周期负责，包括它的开发，包括需求的实现，包括我整个的运维，那么这样其实就是到了我们现在的一个架构。

在这种架构下面，我们面临的挑战是什么呢？就是有大量的网络调用，对吧。那每个服务其实用的资源都很少，所以当我们的物理服务器变得越来越强大的时候，我又把整个业务拆散了。

那么，如果要提高整个物理机的资源利用率，是不是就需要把多个微服务部在一个机器上。不像以前，以前我就一台机器部一个应用结束了，现在微服务架构下面可能是一台物理机上部上上百个服务。

那这样部署的话，会有什么问题？就是这些服务之间的隔离性是做的不好的，它们彼此可见，有可能A服务出问题就把B服务给给影响了，比如说我一个应用出了OOM对吧，内存泄露，那我可能把整个机器的资源吃掉了。

所以后面就出现了虚拟化技术，就是我把一个物理机切成不同的虚拟机，然后再把业务代码部署到虚拟机里面。服务和服务之间的调用，其实就是每一个服务都是部署在自己的虚拟机里面的，它们都是根据网络协议去调用的，比如说我们每个服务都会去listen的一个IP地址和一个端口上面，那么你接下来微服务人员就可以调用了，这是架构的一个演进。

1.2 不同架构的优劣

1. 单体架构

接下来我们来看看不同架构的一个优劣。这里分层架构就是专指刚才的图左半边的那个，单体架构就是所有的业务逻辑揉在一起。那它有个什么好处呢？因为它只有一份代码，然后构建出来也只有一份部署，所以它的部署测试很简单。然后横向扩展，我就直接多放两台机器，我一台机器不行就放两台机器，所以分层架构，它就是维护很简单，因为面向的对象少，我可能就面向一份代码。

那么，这样的架构面向企业，对简单系统来说是非常轻松的。一般来说，假设你是创业，你只要写一个小的网站，代码非常少呢，我觉得这种是适合的。但是这种架构，到了复杂系统就会出现我刚才说的很多问题了。你复杂到一定程度已经没有人能够清晰的知道每一个组件了，所以这个东西就没有办法维护了，然后又因为它是单进程的，它的启动、部署、安装等，都会很慢。你发生任何的变更，都会引发大的问题，还有它对资源利用，对于这种这种快速部署，都有负面的影响。

2. 微服务

那我们再看微服务：把一个大的应用拆成了不同的微服务，那么它也其实也是有好处和坏处的。一般我们要遵循一些原则去拆分。那这个原则我每次都要强调跟大家说你拆微服务或者做系统调用/系统设计的时候，最根本的一个原则就是高内聚低耦合。

怎么理解呢，就是把相关的业务逻辑放在一个子项目里面。然后，这是第一，就是当你一个大的系统要拆分不同子服务的时候，你怎么去拆分？或者当你设计一个系统的时候，你怎么决定哪个哪个功能放在哪个子系统里面？那么高内聚就是第一指导原则，就是你要把一些相关的功能放在一个子系统里，然后把不那么相关的功能拆分到不同的子系统里面。

那么，尽量让不同的子系统之间，它的耦合度低，可以通过简单的网络调用就能实现一个业务逻辑，那这基本上是它最核心的一个指导原则。当然，还有很很多其他的我就不一一说了。

对于复杂系统来说，这种微服务架构一定是更好的，下面说说它有哪些优势。

第一微服务的体量小，所以启动速度快。比如说在云原生这种架构下，我要启动启动一个服务，很快可能秒级就起来了，但传统的有可能是10分钟20分钟甚至几个小时都起不来。

其次就是可以节省资源：一个大的系统拆分成不同的不同的子系统，有些子系统面向前端，有些子系统面向后端，有些可能面临的并发请求很高，有些面临的并发请求很低，那么对于这种不同、面向不同场景，不同客户的应用，他们所需要的这种SLA是不一样的。有些我可能面向用户的，可能你必须是高可用的，那面向管理员的一些管控系统，那可能无所谓，down就down了。请求大的时候，我可以把面向用户的这一部分把它扩容，让它有更多的CPU的，更多的memory去处理，其实在整体上其实是节省资源的。

但是相应的微服务会带来复杂性，因为你把可能把一个应用一份代码切成了几十份，上百份，上千份，那要让一个人去维护，其实也不太可能，因为它比原来更复杂了。

但是这样的好处是什么呢？子系统和子系统之间的边界非常清晰，我们可以把我整个公司的这种组织架构跟我的应用去配合。一部分人维护这几个模块，一部分人维护这几个模块，他们为他们全权负责。那这是微服务架构下面推动的一些组织结构的变化。很多公司都是这样，比如说eBay，我相信现在大部分公司应该都是这样了，都有不同的业务部。腾讯也是一样对吧，那么不同的业务部为不同的子系统去负责。

1.3 微服务改造

这里面提供了一定的微服务改造建议，就是我要去做微服务的改造，比如说我有个单体应用。我怎么样去做微服务改造呢？那有些工具其实是可以做的。

分离微服务的方法建议：

审视并发现可以分离的业务逻辑

寻找天生隔离的代码模块，可以借助于静态代码分析工具

不同并发规模，不同内存需求的模块都可以分离出不同的微服务，此方法可提高资源利用率，节省成本

一些常用的可微服务化的组件：

用户和账户管理

授权和会话管理

系统配置

通知和通讯服务

照片，多媒体，元数据等

分解原则：基于 Size, scope and capabilities

第一，就看你的业务逻辑，独立的业务逻辑，它就是天然是个子系统。然后有些工具其实可以辅助你做决策的，比如说有些静态代码扫描工具，你可以一扫代码发现，诶，package a 和 package b 之间几乎没有网络调用或者是函数调用，那它们两个就是独立的两个模块，那切开来就很很简单了。

那还有一些我们可以从功能层面去，有一些practice，有些最佳实践，比如说用户账户管理这些、会话授权这些子功能，它就是天然的一个独立模块，一般都会被抽出来。

还有些时候，比如说你面向一个系统，然后你接收了一些新的需求，那么你可能就会天然去想到说我这个需求是做在现有的哪个系统里面好呢，还是说我就做一个新的系统。那如果是做新的子系统，它就是天然的，就变成一个新的微服务了。

所以这里面有一些分解原则，其实就是要基于你这个微服务的大小，它的功能范围，还有能力去定义你的微服务。

1.4 微服务间通讯

点对点：

多用于系统内部多组件之间通讯；

有大量的重复模块如认证授权；

缺少统一规范，如监控，审计等功能；

后期维护成本高，服务和服务的依赖关系错综复杂难以管理。

那我们再谈，说这么多微服务架构的主要目的是什么？我们其实最终的目的是要把微服务和微服务之间的通讯理顺的。你有这么多微服务，那么微服务之间一定会有一个互相调用的关系。

一般来说，有两种不同的调用关系。

第一种叫点对点，那么这个点对点怎么理解呢？就是我有这么多微服务，那我客户端可以说我客户端要去访问某个服务，那这些服务呢它就、它要去调别的微服务。从比较大的视图来看，这种架构下面不同的微服务其实是一个散列的，就是没有一个中心点的。这是其中的一种微服务架构。

另外一种就是基于API网关的，基于API网关的这种微服务架构，从字面的意思，或者看这个图就很直观了。我有很多微服务，那微服务前面其实有一个API网关的。对于客户端来说，我要调用任何的微服务，都是从API网关去走。那API网关来负责把这个请求接入到、转入到不同的微服务里面去。

API 网关

基于一个轻量级的 message gateway

新 API 通过注册至 Gateway 实现

整合实现 Common function

这种模式有跟刚才的点对点的方式比较，有哪些优势呢？就是因为你所有的请求都从API往关走，那么，它本身就可以做一些统一的逻辑了，比如说日志授权，审计等。所以这些东西它都是可以做的。

任何的系统，大的系统很多时候都会提供一个API网关，比如说后面我们要讲kubernetes。kubernetes 本身就有一个API server，它就是API网关。

不管哪一种架构，它核心的思想就微服务架构一个核心要去解决的问题就是肯定有一个服务通信的双方，有一个A服务去调用B服务的时候，我要做什么事情？

需要先有一种服务发现的机制，知道B服务在哪儿。

第二，我要通过一个网络调用去调用B服务的IP加端口，这就意味着我们的每一个服务微服务其实都要发布出来。那它发布出来就是我任何一个应用的进程都要listen在一个IP加端口的这样一个地址上面，也就是说我要有独立的网络配置。

这是一个大前提，微服务的架构才能出现。那么接下来就去了解容器技术，要解决哪些问题。