浅谈多层技术架构与企业技术竞争力的构建

最近笔者在公司内部做了关于未来技术架构演进的分享,在这里重新整理一下,希望对读者有所启发。

一个企业的良好发展,离不开其核心竞争力。在技术上来说,需要构建技术竞争力,一个拥有技术竞争力的企业,能更好的为业务服务,更好的吸引优秀的技术人员,最终形成一个良好的闭环,技术竞争力转化为驱动力,让企业更快更稳的发展。

本文尝试通过多层技术架构入手,旨在探索一种方式,构建企业技术竞争力,通过技术提高生产力甚至颠覆业务组织形式。

什么是多层架构

所谓的多层技术架构,就是通过合理的层次划分,将一个企业的整体技术架构分为多个层次,层与层之间相对独立。通过分层,实现每一层的平台化,底层向上层提供服务能力,上层而无需了解底层运行细节。

分层是一个纵向的概念,与之对应的横向是分模块,层是一个更大的概念,每层可能由很多模块组成。当然两者的很多理念都是类似的,都是通过良好的封装,降低耦合实现高内聚。

如何划分多层架构

我们先来看一张图:

在这张图中,我们将整个技术架构划分成了7个相互独立的部分,下面分别介绍:

资源管理层

在云计算技术兴起后,各大云服务厂商(比如阿里云,AWS)通过使用虚拟化技术简化了计算资源的管理,实现一键创建云主机,并灵活扩容,不再需要以前托管服务器,手动管理服务器的总总工作,大大提高了的生产效率。

最近几年,随着轻量级容器技术的应用,Docker 风声水起,资源管理变得更加的容易和轻量,比如通过 Kubernetes 能够实现按需更灵活快捷的资源管理,从而更方便的组建公司级 PaaS 平台。

对于一般的企业而言,这一层更多的利用现有技术为主,包括使用已有的 IaaS 云平台和开源的资源调度工具。

平台服务层

如果说资源管理层是我们的操作系统,那么平台服务就是我们的 libc 基础库,有了它的存在,让我们更加方便的的构建云端上层应用,让上层应用专心关注业务,而不需要关心和维护底层平台。

那哪些服务可以划分为平台服务呢?我觉得平台服务应该满足以下几个特点:

  1. 适用面广,平台服务应该有及其广阔的使用场景
  2. 抽象度高,平台服务应该是高度抽象的,为业务提供基础能力

按照这个标准,如下这些服务都可以归为平台服务:

  1. 队列服务
  2. 推送服务
  3. 对象存储与处理服务
  4. 中心任务调度服务
  5. 等等

这一层中,很多的云厂商都提供的对应的产品,如果没有特殊要求,拿来就可以使用。

基础服务层

相比平台服务,基础服务更偏业务,它是对不同类型业务的抽象,虽说它的抽象程度和通用性不足平台服务,但其给开发者的方便程度确是很大的,如果抽象合理,应用得当,能够极大的提升开发效率。

基础服务层可以对标 BaaS (后端即服务),通过基础服务层,我们将涉及的业务进行更宏观全方位的抽象,设计出一个更通用的基础服务,避免相类似的业务被重复的实现了多次,提高技术含量,技术价值最大化。

就笔者所在公司的 SaaS 系统而言,如果下的一些服务都是可以做成基础服务:

1、用户与权限服务

用户与权限管理是每个系统都必不可少的功能 ,其结构大同小异,如果将其独立成一个基础服务,让不同产品都可以使用,让新产品的开发更方便快捷。

2、表单服务

对于很多产品而言(toB 产品尤甚),我们大量的工作都在处理各种表单,处理起来繁杂冗余,技术含量不高。如果我们提供同一的表单引擎,统一管理和设计表单,并提供配套设施,将大大提高工作效率。

3、流程引擎

在表单服务的基础上,再辅以流程引擎,让数据在不同的流程中流转起来,匹配业务流程。如此便可以不编写代码或者只需少量代码就能实现一个自定义的业务流程。

4、数据分析服务

有了表单服务和流程引擎还不够,如果再结合数据分析服务,让数据是可以通过各种方式被分析,就可以让数据产生更大的价值,帮助决策。通过保单服务、流程引擎、数据分析服务的完美结合,我们有机会以更方便快捷的方式,满足客户需求。

基础服务层是对业务的高度抽象,不同的业务形态可能形成不同的抽象,通过基础服务层的建设,让上层业务的开发就像搭积木一样,通过组合,更快的响应客户需求,同时避免开发人员疲于奔命。

业务层

有了前面的支撑,业务的开发就显得简单多了。当然为了最终服务的可靠性,在设计业务服务的时候,需要考虑以下几个原则。

隔离性

不同的业务服务直接应该具有一定的隔离性,防止因一个服务故障而将其他服务拖垮的情况。对于一些有突发流量的服务,应该考虑增强其独立性,从而减少对其他服务的影响。

无状态

业务服务应该是无状态的,这样方便服务的水平扩展,通过横向的机器扩展实现高并发的需要。

服务降级

故障必不可免,如果如果其他服务发生故障,可能需要设计一定的降级措施,避免服务发生联机失败,减少损失。

接入层

对于原来的单块应用来说,接入层很简单,只有简单的 DNS 加上 Nginx 做一个反向代理。但当我们的服务越来越多,变成一个复杂的分布式系统的时候,接入层的存在就显得必须且非常重要了,接入层从外到内,有如下几个层级:

1、DNS

接入层的最外层是 DNS,通过智能 DNS 解析,给不同的区域,运营商分配最合适的线路,达到访问最优的效果。当然 DNS 还能做负载均衡,只是因为 DNS 的更新策略问题,不能做到及时恢复,一般我们需要配合负载均衡使用。

2、负载均衡

负载均衡分为四层负载均衡和七层负载均衡。

四层负载均衡是工作在 TCP/IP 层的负载均衡器,比如 LVS,因为工作在四层的原因,这里的负载均衡性能好,但灵活性不是很高,如果不是特别大规模的应用,这一层可能不需要。

七层的负载均衡能够解析具体的协议,比如 HTTP,能够根据请求的信息灵活的定义规则,比如进行简单鉴权,比如统一添加 RequestID。常见的 Nginx、HAProxy 都可以作为七层负载均衡。

通过负载均衡器,我们可以实现:

  1. 负载均衡,将请求按需分配到不同的服务实例上,实现故障转移和高可用
  2. TLS offloading,将外部的 HTTPS 流量转成内网 HTTP 流量
  3. 限流,让后端服务始终工作在最高效的状态
  4. 简单鉴权处理(七层)
  5. 异常流程检测,IP 屏蔽
  6. DDoS 防护

3、WAF

WAF 是 Web 应用防火墙,现在的互联网充满了太多的不安全因素,于是 WAF 应运而生,WAF 通过规则或者学习的方式识别恶意请求,让它们没有机会到达后端服务器,保障 Web 安全。

WAF 可以在七层负载均衡器中实现,有的 WAF 有附带负载均衡的功能。

数据层

上面的几个层中,它们大多的服务都是没有状态的,这使得它们具备良好的 扩展性。但在真实的世界中,有许许多多的状态和数据需要被持久化的保存。

通过引入数据层,将数据存储服务化,业务无需关注数据存储的底层细节,比如备份,容灾,扩展性。

当然,构建这样一个数据层就需要考虑很多东西,包括但不限于如下几个方面:

  1. 数据备份与恢复,容灾相关考虑
  2. 水平扩展性,支持大量和大并发的数据存储(分布式存储 or 中间件)
  3. 完善开发工具支持,方便业务方定位问题

最后,数据层也会细分很多的服务,比如关系型数据库,文档数据库,缓存,队列等,不同的应用场景需要不同的数据层支持。

监控层

我们的服务时刻面临挑战,有来自用户突发流量,有来自攻击者的恶意流量,有研发团队迭代产生的问题,不一而足。

为了让我们更快的发现问题,进而解决问题,监控是保证高可用服务比不可少的支撑系统,其重要性不言而喻。通过监控可以:

  1. 最基本的反应系统的健康状态
  2. 出现问题时分析问题出现的原因
  3. 自动扩容与故障处理
  4. 作为系统优化的数据数据支撑,比如性能优化
  5. 更甚一步,通过监控建立业务模型(调用链),实现故障的根因分析(AiOps)

多层架构优势与可能性

建设多层技术架构体系,我们有如下几个方面的优势和可能性:

更好的分工协作

通过技术架构,把涉及的有所工作进行统筹划分,特别是团队比较大的时候,让每个团队都能够在既定的上下文中工作,降低沟通成本,同时减少重复造轮子,实现技术共享。

提升技术竞争力

笔者相信,一个优秀技术人员更希望从事有挑战的工作,通过越来越大的挑战,实现个人能力的提升。

作为企业也是一样,我们需要为他们提供这样的环境,能够让技术人员有机会接触这样的挑战,最终企业与个人达到一个良好的化学反应,提升企业与个人的综合技术竞争力。

颠覆业务形态

技术发展到一定程度,它可能不仅仅能为我们提高效率,它还可能是创新的土壤,有机会颠覆已有的业务形态或者发现更多的机会。

比如说,亚马逊作为一家电子商务公司,它的 AWS 云计算服务世界第一;再比如说,Salesforce 作为 TOP 1 的 SaaS 公司,对外开放了技术能力,让人可以方便的构建应用,满足不同的应用场景。

通过技术创新,它们已经颠覆了原本的样子,与竞争者不在一个维度。虽然这可遇不可求,但梦想还是要有的,万一实现了呢~