企业技术架构变迁之路

概述

随着互联网业务的极速增长,传统的单体应用系统变得越来越笨重,系统规模所带来的挑战也在不断加大。为了解决传统技术架构所产生的问题,应用架构也在发生着不断的变化,本文将从几种应用架构的介绍和对比来阐述企业应用架构的变迁。

Monomer application introduction 单体应用介绍

  • 什么是单体应用架构:单体应用(monolith application)就是将应用程序的所有功能都打包成一个独立的单元,可以是JAR、WAR、EAR或其它归档格式
  • 单体应用架构的优势:结构单一,开发简单;IDE支持友好;模块代码集成在一块,便于共享;服务和特性在部署后均能使用,简化了测试过程;基于单个文件的部署,部署简单
  • 单体应用架构的缺陷:各模块集成在一起,耦合度较高;系统优化或BUG修复需要整个应用重新发布,部署效率低;技术单一,不能根据业务场景灵活变更技术路线;系统设计或代码难以修改,技术债务日益凸显

Monomer application framework 传统应用架构- 单体应用

Micro service application introduction 微服务应用介绍

  • 什么是微服务架构:微服务是一种新的软件架构风格,旨在通过将单体应用分解成多个更小的服务,每个服务有自己的归档文件,单独部署,然后共同组成一个或多个应用程序
  • 微服务架构的优势:通过分解巨大单体式应用为多个服务,有效降低了复杂性问题;每个服务都可以有专门开发团队,开发者可以自由选择开发技术;每个微服务独立的部署,不再需要协调其它服务部署的影响;架构模式可独立扩展
  • 微服务架构的缺陷:分布式系统,复杂性较高;分区数据库架构,数据一致性较难保证;独立部署所产生的配置、监控较为复杂;功能可能会涉及到多个服务,不便于测试

Micro service framework 微服务技术架构

Why to implement micro service 为什么要实施微服务?

  • 传统应用之痛:传统单体应用架构把整个应用都封装在一个Webapp中,随着业务的不断壮大,单体应用变得越来越庞大,无法进行拆分,即使通过单体应用做的水平拓展,能够部分解决单机故障,负债均衡等问题,但系统资源浪费、部署效率低下、技术选型单一等硬伤依然没法解决
  • 微服务应用之光:面对传统应用架构的诸多问题,以及现在互联网行业的快速发展,对系统的要求日益增高,具备复杂度可控、容错机制好、拓展性强、更快应对变化等特点的微服务架构应运而生。本质上讲微服务是偏向技术架构的模型,它应具备如下特性:
  • 开发简单:基于现有的成熟微服务框架(如Spring Cloud),开发效率和学习成本较低
  • 部署简单:使用Docker容器等技术,能够实现部署的自动化和弹性拓展
  • 监控简单:完善的日志及监控机制,出现问题时提前预警和自动熔断
  • 运维简单:可对系统进行弹性伸缩,快速实现服务水平拓展,服务降级等
  • 高性能:不会有性能瓶颈,引入负载小
  • 快速响应:面对业务的不断变化,系统能够迅速响应调整,快速迭代

How to implement micro services 怎样实施微服务

  • 交付流程:使用微服务架构进行开发,需要针对每一个特定微服务进行设计、开发、测试及部署
  • 设计阶段:架构师将产品功能拆分出多个微服务,并设计出API接口,给出API文档,包括API名称、版本、请求参数、相应结果、错误代码及错误信息等
  • 开发阶段:后端工程师实现API接口开发,并完成API单元测试;前端工程师并行开发Web UI部分,过程中可根据API文档造一些模拟的静态数据,这样可以无须等待后端API开发完成后才能进行工作
  • 测试阶段:前后端工程师将自己的程序部署到服务器,测试工程师进行技术层面和功能层面的测试,随后交付产品经理或关键用户进行验收
  • 部署阶段:运维工程师将程序部署到预发布环境,测试工程师或关键用户继续进行一些关键的集成测试和流程测试,待确认无问题后,运维工程师将程序部署到生产环境
  • 特别说明:交付过程中涉及到多个角色,不是每一个特定角色都需要专人负责,一个工程师处理多个角色的事情也非常常见,另外为了提高工作效率,在测试和部署都需要做到更加自动化和智能化

Micro service architecture selection 微服务技术架构选型

架构拓展:Spring官方在Spring Boot的基础上,封装了Netflix相关组件,开源了Spring Cloud项目,目前已逐渐成为微服务主流技术架构



  • 微信公众号
  • img