历史总是惊人的相似,合久必分,分久必合。
我们经历了“合”:单体架构(软)、计算能力超强的小型机(硬)到“分”:分布式架构的转变,后期可能会将“分”发挥到了极致(去中心化的分布式,如区块链),最后很可能再经历“合”:计算和存储能力超强的“智人”(边缘计算的升级,集超级计算和存储一身的人工智能)。
那单体架构为什么要演进呢?笔者认为主要体现在如下3点:
互联网发展对应用开发提出了更高要求。业务的量级和效率提高,传统的单体架构将出现瓶颈。
互联网飞速发展的同时,也推动了云计算、大数据、人工智能的快速落地,数据采集遍布软件、硬件,数据本身价值也得到提升。使用微服务架构恰好解决了大部分痛点。
数据联通性的需求:系统间,系统与硬件之间,数据对接必须保证高性能、高安全、高标准.
我们已经意识到:技术架构受公司业务和组织架构影响。作为从单体架构过来的人,起初我是拒绝的,或者说担心我们的业务被拆分后出现不稳定状况。但是随着业务突然扩展,业务不断细分,敏捷开发和配套的技术方案迫在眉睫。总归是要迈出这第一步,2015年下半年,我们踏上了微服务的不归路。
首先根据总体业务规划,我们先做了初步的技术架构规划,然后确定选型思路:
有了思路,根据我们的方法论,要根据现有的主流架构做一番比较和筛选然后才能最终敲定:
受限于当时技术团队的资源限制,我们根据最小阻力原则,选择了SpringCloud.spring cloud提供了开发分布式服务系统的一些常用组件,例如服务注册和发现、配置中心、熔断器、智能路由、微代理、控制总线、全局锁、分布式会话等。如下图所示:
经过短期探索调试后准备开始试水,暂时不敢动主流业务,我们就从对外提供的一些接口服务和部分独立系统开始下手,这个阶段我们尝到了甜头,但紧随其后就是各种填坑,质疑不断,不过最后我们还是坚持下来。
微服务初步改造后,给我们带来了一些额外困扰:
显然,我们不能通过jar包启动的方式去维护大批量微服务,而且这些服务部署在一起还相互影响。
在刚引入微服务后不久,我们并没有急于替换所有业务,而是把基础运维工作做好,随后我们引入了Docker。Docker给我们带来了:
光有Docker还不够,我们发现引入Docker容器后,虽然解决了一些问题,但是还不够。我们运维起来太麻烦,各种Docker命令还有脚本,甚至我们都不知道我们到底有多少服务,它们健康状态、资源占用怎么样,当业务量激增难道我们永远都是被动且手动的去做服务伸缩么?
我们随后引入了容器编排工具:Rancher,并围绕Rancher + Docker构建了一套容器云和一套DevOps工具集(本文不做重点描述,欢迎关注后续文章)。
当我们从大量运维工作中解放出来后,我们发现,小团队也可以做大事情:
虽然微服架构替换现有业务说起来容易,但整个替换过程持续了将近2年,到了2017年底,我们已经形成一套基于容器云和微服务架构体系的解决方案,整体架构如下图所示:
原文链接: https://mp.weixin.qq.com/s/sOttbvwpipjY123KXaXQ3A