浅谈微服务架构搭载容器云构建历程

开发 架构
历史总是惊人的相似,合久必分,分久必合。我们经历了“合”:单体架构(软)、计算能力超强的小型机(硬)到“分”:分布式架构的转变,后期可能会将“分”发挥到了极致(去中心化的分布式,如区块链),最后很可能再经历“合”:计算和存储能力超强的“智人”。

 服务简史

历史总是惊人的相似,合久必分,分久必合。

[[272671]]

我们经历了“合”:单体架构(软)、计算能力超强的小型机(硬)到“分”:分布式架构的转变,后期可能会将“分”发挥到了极致(去中心化的分布式,如区块链),最后很可能再经历“合”:计算和存储能力超强的“智人”(边缘计算的升级,集超级计算和存储一身的人工智能)。

01.png

那单体架构为什么要演进呢?笔者认为主要体现在如下3点:

1.业务量在增加

互联网发展对应用开发提出了更高要求。业务的量级和效率提高,传统的单体架构将出现瓶颈。

2.能采集的信息越来越多

互联网飞速发展的同时,也推动了云计算、大数据、人工智能的快速落地,数据采集遍布软件、硬件,数据本身价值也得到提升。使用微服务架构恰好解决了大部分痛点。

3.万物互联

数据联通性的需求:系统间,系统与硬件之间,数据对接必须保证高性能、高安全、高标准.

微服务架构

我们已经意识到:技术架构受公司业务和组织架构影响。作为从单体架构过来的人,起初我是拒绝的,或者说担心我们的业务被拆分后出现不稳定状况。但是随着业务突然扩展,业务不断细分,敏捷开发和配套的技术方案迫在眉睫。总归是要迈出这第一步,2015年下半年,我们踏上了微服务的不归路。

技术选型

首先根据总体业务规划,我们先做了初步的技术架构规划,然后确定选型思路:

  • 不绑定到特定的框架,跨语言
  • 服务最好是Restful风格(风格极简,且是主流标准)
  • 足够简单,容易落地,将来能扩展
  • 稳定性强
  • 和Docker相容性好(自动化运维)

有了思路,根据我们的方法论,要根据现有的主流架构做一番比较和筛选然后才能最终敲定:

  1. Dubbo、DubboX:优势在于全栈、服务治理的支持性强,是阿里巴巴开源且经过阿里巴巴实践的产品,中文文档很多,社区活跃。但选型时停止维护,跨语言难度较大
  2. Spring Cloud:是Spring旗下的子项目,社区足够强大,架构本身简单方便,几乎零配置。基于RESTful API,跨语言。但当时Spring Cloud实践较少,且性能和RPC相比不占优势
  3. Motan:是微博平台微服务框架,承载了微博平台千亿次调用业务。优势在于性能,且实现模块化、结构简单、易于使用、跨语言,但对于复杂的业务支持不够好
  4. Thrift、gRPC:并不能算作微服务框架,自身并不包括服务发现等必要特性
  5. Istio:Service Mesh思想,可以看作是微服务架构的一次升级,和serverless要解决的问题类似,让业务/算法与服务治理剥离,当时技术还不成熟(这个选型时后来补充的)

受限于当时技术团队的资源限制,我们根据最小阻力原则,选择了SpringCloud.spring cloud提供了开发分布式服务系统的一些常用组件,例如服务注册和发现、配置中心、熔断器、智能路由、微代理、控制总线、全局锁、分布式会话等。如下图所示:

02.png

架构替换

经过短期探索调试后准备开始试水,暂时不敢动主流业务,我们就从对外提供的一些接口服务和部分独立系统开始下手,这个阶段我们尝到了甜头,但紧随其后就是各种填坑,质疑不断,不过最后我们还是坚持下来。

构建容器云支撑

微服务初步改造后,给我们带来了一些额外困扰:

  1. 微服务过多,服务治理成本高,不利于系统维护。
  2. 分布式系统开发的技术成本高(容错、分布式事务等),对团队挑战大。

显然,我们不能通过jar包启动的方式去维护大批量微服务,而且这些服务部署在一起还相互影响。

啥是配齐?容器云+微服务

在刚引入微服务后不久,我们并没有急于替换所有业务,而是把基础运维工作做好,随后我们引入了Docker。Docker给我们带来了:

  1. 迭代效率提升支撑:Docker 用户发布软件的频率平均快了 7 倍
  2. 环境可移植:Docker是一个代码运输集装箱系统,它使得通过Linux的软件开发和交付变得很容易
  3. 更快且更小:充分利用服务器资源,一台虚机可以跑几十个容器
  4. 标准统一:可实现环境甚至架构的复制性

光有Docker还不够,我们发现引入Docker容器后,虽然解决了一些问题,但是还不够。我们运维起来太麻烦,各种Docker命令还有脚本,甚至我们都不知道我们到底有多少服务,它们健康状态、资源占用怎么样,当业务量激增难道我们永远都是被动且手动的去做服务伸缩么?

我们随后引入了容器编排工具:Rancher,并围绕Rancher + Docker构建了一套容器云和一套DevOps工具集(本文不做重点描述,欢迎关注后续文章)。

当我们从大量运维工作中解放出来后,我们发现,小团队也可以做大事情:

  1. 小团队作战,敏捷开发方式,替换其他业务
  2. 解决方案打包,一键部署
  3. 抽出人手构建我们同等重要的DPaaS平台
  4. 部分业务变化快的模块快速优化甚至重构

初见成果

虽然微服架构替换现有业务说起来容易,但整个替换过程持续了将近2年,到了2017年底,我们已经形成一套基于容器云和微服务架构体系的解决方案,整体架构如下图所示:

 

 

责任编辑:华轩 来源: 老刘的技术栈
相关推荐

2023-09-03 16:54:59

容器架构微服务

2021-04-06 09:43:41

微服务架构数据

2015-07-22 15:19:46

Docker云计算微服务

2017-07-04 14:57:40

微服务paasdocker

2019-07-11 15:25:02

架构运维技术

2015-07-29 16:23:07

2017-06-26 09:06:10

Spring Clou微服务架构

2020-12-10 08:00:00

开发.NET工具

2018-03-26 04:53:46

Serverless微服务架构

2018-01-10 14:22:05

2017-09-04 16:15:44

服务网关架构

2017-12-20 15:37:39

Spring Clou微服务架构

2021-12-29 08:30:48

微服务架构开发

2023-10-12 09:48:00

微服务工具

2021-09-27 16:58:51

当当网容器微服务

2023-08-27 16:13:50

架构微服务器

2023-07-28 09:23:24

微服务架构

2017-07-03 09:50:07

Spring Clou微服务架构

2017-08-09 15:50:47

Spring Clou微服务架构

2017-08-10 11:15:05

Spring Clou微服务架构
点赞
收藏

51CTO技术栈公众号