云原生集成开发环境——TitanIDE
通过网页在任何地方更安全、更高效地编码2022-07-12
902
微服务(Microservice),一种用于构建应用的分布式架构框架,其解决了传统软件开发面临着很多的问题,比如:代码重复率高、代码庞大难以维护、无法快速迭代、测试成本高、可伸缩性差、可靠性差、模块间高度依赖等。
什么是微服务?
ThoughtWorks 首席科学家马丁·福勒(Martin Fowler)曾说过:微服务架构风格是以一组小服务来开发单个应用程序的方法,每一个服务运行在自己独立的进程中并且使用轻量的方法通信,通常是一个HTTP API接口。这些服务围绕相关业务范围构建并且由全自动化部署机器独立部署。这些服务只需要最低限度的管理,可以用不同的编程语言去编写并且使用不同的数据存储技术。
聊到微服务架构,不得不说说上一代传统单体架构。单块应用目前应用还是较多的,它部署容易,但任何改动都会牵一发动全身。哪怕是对应用程序一个小地方的改变,都需要整个单块应用被重新构建和部署。如要实现缩放,需要缩放整个应用程序而不是应用程序的某一部分,这要求更多的资源。
单体架构 VS 微服务框架
微服务架构的通用特性
根据MartinFowler的分析,微服务架构具有一些通用特性,但并非所有微服务架构应用都必须具备所有这些特性。
为什么要采用微服务架构?
软件架构的发展经历了从单体结构、垂直架构、SOA架构到微服务架构的过程,各个架构的特点如下图所示:
各架构特点
相对于传统单体架构来说,微服务架构有着绝对的优势,企业应用向微服务架构演进的趋势不可逆转。
传统架构 VS 微服务架构
微服务架构的优点
因此,企业应用架构使用微服务的先决条件要提前考虑到位。
使用微服务的先决条件
当软件的复杂度很低的时候,单体架构下的生产力是要高于微服务架构的,但随着复杂度的不断增加,无论是单体应用还是微服务应用的生产力都会下降,只是微服务架构的下降会相对缓慢一些。
如果长期业务规划不需要微服务架构或者团队不具备实施微服务一些基本的条件,不建议实施微服务,或者应用从试点入手,逐步在团队中推行微服务架构。
如何实施微服务架构
微服务架构4大设计原则:
· AKF拆分:AKF扩展立方体(Scalability Cube),是《架构即未来》一书中提出的可扩展模型,这个立方体有三个轴线,每个轴线描述扩展性的一个维度,他们分别是产品、流程和团队。
· 前后端分离:前后端分离原则,简单来讲就是前端和后端的代码分离也就是技术上做分离,推荐的模式是最好直接采用物理分离的方式部署,进一步促使进行更彻底的分离。
· 无状态服务:首先说一下什么是状态:如果一个数据需要被多个服务共享,才能完成一笔交易,那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务,反之称为无状态服务。那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态,表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务,那么状态数据也就相应的迁移到对应的“有状态数据服务”中。
· Rest 通信风格:作为一个原则来讲本来应该是个“无状态通信原则”,在这里推荐一个实践优选的 Restful 通信风格 ,因为他有很多好处:
行云系统设计的微服务实践
行云创新基于微框架 SpringBoot 实践,涵盖了微服务模块50个,多语言开发框架,多协议支持,并且应用基于容器技术等。
主要模块有:
Mart — 应用商店
Factory—应用工厂
Composer—设计器
APIGateway—API网关
Admin—运维中心
DNS—外部DNS服务
Orca—调度器
Blueprint Repo—蓝图存储
Internal DNS—内部DNS服务
Turtle —策略管理
Metrics—统计数据
Alert—监控告警
杭州—区域,包括容器集群等
Gateway—服务接入网关
行云 SpringBoot 实践架构图
总结
当前,以微服务、DevOps、容器、多云业务管理为代表的云原生技术已经广泛成熟应用,成为加速企业数字化业务高效创新、实现企业数字化转型的最佳技术支撑。而信创支持、国产化支持,是中国企业数字化转型不得不满足的基本要求。更有专家指出,在关乎企业生存的必选项“数字化转型”以及国家信创战略的共同冲击下,企业需要改变现有业务和IT的架构,更快速地应对挑战、响应变化,增强自身的竞争力。
-------------