微服务架构系列前序文章:
从准备引进微服务这套技术栈的想法开始,到一个微服务架构的新系统部署上线,这大概需要经过哪些关键步骤呢?按照相对规范的研发流程来看,我们需要经过下列四个研发阶段:
微服务的开发测试,跟单体式的应用开发类似,关键区别就是以HTTP RESTful API的形式对外提供服务,测试时要以这些API为切入口,这些API规格就是对外服务的契约,服务之间的合作是以这些契约为基础的。契约,让分工的边界更清晰,让合作更规范。微服务的发布部署主要依赖于容器云和DevOps平台,如果没有这些辅助系统的支撑,那微服务架构的系统是很难运营维护的。
物流配送、电子支付等是电子商务的基础设施,没有这些基础设施的强力支持,电子商务很难取得大的发展,容器云和DevOps平台就是微服务的基础设施,在评估引进微服务架构时,我们需要先看看基础设施是否就绪,否则就事倍功半,即使搭建了完美的微服务架构也很难有好的效果。接下来,我们重点看看架构设计和环境搭建这两个阶段跟单体式应用有什么区别。以前后端分离方案为例,架构设计阶段的主要产出包括下面五类:
在环境搭建阶段,资源评估和网络开墙都有些新内容要熟悉的。在单体式架构下,我们主要使用物理机或虚拟机,估算资源使用量相对简单,只需按照生产最小高可用或业务并发访问量来评估物理机或虚拟机的数量与规格(CPU核数、内存大小、存储等)。微服务依赖容器云,除了估算容器的数量与规格外,我们还需要将容器用量转换成物理机或虚拟机的用量,考虑到容器云是在物理机或虚拟机上铺设了一层容器相关的设施,那么物理机或虚拟机的用量不再是容器用量的简单累加,通常还要乘上一个系数(经验值:1.3),以便预留资源用于运行容器云相关的组件等。
资源估算时要满足生产最小高可用和业务并发访问量,其中生产最小高可用是指构成系统的每个组件必须是高可用的,即搭建主从、双活等架构,每个组件至少配备两个实例。在此基础上,我们还要预估业务访问量,每个承担业务流量的组件必须要搭建足够多的实例。除此之外,我们还要按网络区域来分别估算资源,因为不同网络区域需要做物理隔离。在网络开墙环节,我们需要梳理出一个全景图,清楚哪些防火墙必须要开通才能满足业务要求等。
微服务属于分布式系统架构,主要是为了应对业务互联网化所带来的海量用户高并发等挑战。从这个角度分析,符合上述场景的系统最具紧迫性改造成微服务架构。也许你负责构建的系统是面向内部用户的,业务稳定,用户量也较小,平时前端变化频次也低,偶尔有些报表类需求,后端也不用过多考虑扩展性、可用性和性能等特性,就眼前看来,你会觉得没有必要采用微服务架构。但从公司、团队和个人的远期发展规划看,不远的将来我们都要掌握微服务架构,用云原生技术栈打造新系统,适应新的云化基础设施,面向全网用户提供创新服务,而当下正是实践新技术的最佳时机。
内部系统不存在太大的业务压力,这样我们就可以更加从容地使用新技术,不需要边开车边换轮胎。当然,在拥抱新技术时步子不能迈得太大,我们可以选择从非核心系统开始微服务化,在这个过程中完成对新技术的熟悉,然后再农村包围城市,逐渐将新技术引入到核心系统当中。
所谓的大时代,不过就是一个选择,或去或留?温水煮青蛙,继续开心地使用老技术,还是跳出舒适区拥抱新技术呢?现在我们对微服务的本质有了更进一步的认知,也清楚了微服务架构的演进策略和实施办法,接下来就需要大家撸起袖子动手实践了。
关注「 IT老兵哥 」,赋能程序人生!推荐原创软技能类文章一篇,点击链接查看: 程序员,怎样打造个人影响力?
近期热评系列《 程序员必须懂的架构师入门课 》: