微服务框架技术与应用(五分钟学GIS _ 微服务架构)

本文目录
五分钟学GIS _ 微服务架构
微服务是一种架构思想。将原有的单个业务系统拆分为多个可以独立开发,设计,运行和运维的“小系统”。这些“小系统”之间通过服务完成交互和集成。每个”小系统”除了能处理本身的业务功能外,同时也将自身的能力朝外部发布为服务。
SOA
SOA(面向服务的架构)是一个组件模型,它将应用程序的不同功能单元(称为服务)的紧耦合系统,划分为面向业务的,粗粒度,松耦合,无状态的服务。服务发布出来后,供其他服务调用,一组互相依赖的服务就构成了SOA架构下的系统。
微服务是 SOA 的升级版,做到更细的粒度,处理了更多的问题。
例如图1中将所有的功能打包在一个WAR包里,基本没有外部依赖(除了容器),部署在一个JEE容器(Tomcat,JBoss,WebLogic)里,包含了 DO/DAO,Service,UI等所有逻辑,缺点也非常明显,部署不灵活以及扩展性不够,但我们如果按照图2的为方式,按照业务而不是技术来划分组织,内部各个服务通过REST方式进行沟通,那么可以使平台使部署、管理和服务功能交付变得更加简单。
如果一句话来谈SOA和微服务的区别,即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线,同时SOA的思想进入到单个业务系统内部实现真正的组件化。
微服务与
一般提到微服务都离不开Docker与DevOps,理解微服务架构是核心,Docker是工具,是手段。
Docker容器技术的出现,为微服务提供了更便利的条件,比如更小的部署单元,每个服务可以通过类似Node.js或Spring Boot的技术跑在自己的进程中。可能在几十台计算机中运行成千上万个Docker容器,每个容器都运行着服务的一个实例。随时可以增加某个服务的实例数,或者某个实例崩溃后,在其他的计算机上再创建该服务的新的实例。
DevOps即开发测试和部署运维的一体化。当我们的单体应用拆分为多个“小系统”后,虽然整体架构可以松耦合和可扩展,但是如果拆分的组件越多,这些组件之间本身的部署运维就越复杂。DevOps够实现开发设计到部署运维的一体化。
微服务优势
1. 通过分解巨大单体式应用为多个服务方法解决了复杂性问题。 在功能不变的情况下,应用被分解为多个可管理的分支或服务。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案,由此,单个服务很容易开发、理解和维护。
2. 这种架构使得每个服务都可以有专门开发团队来开发。 开发者可以自由选择开发技术,提供API服务,实现敏捷开发。
3. 微服务架构模式是每个微服务独立的部署。 开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。
4. 微服务架构模式使得每个服务独立扩展。 你可以根据每个服务的规模来部署满足需求的规模。甚至于,你可以使用更适合于服务资源需求的硬件。
四驾马车
最后再谈谈咱们SuperMap家族中的四驾马车(iServer、iExpress、iPortal、iCloudManager),这些产品也是借鉴了微服务设计思想,例如iCloudManager,它可以管理成千上万的Docker容器,将每个Docker完全做到进程级别的隔离,资源占用率又很小,满足微服务架构开发与测试以及自动化部署运维。
微服务架构给客户带来的价值
传统的应用通常为单体架构、单体应用系统,如使用WebSphere、WebLogic或.Net Framework等,从前端到中间件再到后端,各个组件一般集中式的部署在服务器上。后来随着Web Service标准的推出,应用以标准的服务交付,应用间通过远程服务调用(RPC)进行交互,形成了面向服务的架构极大提升了应用组件的标准化程度和系统集成效率。在云原生应用设计中,应用体量更小,因而传统单体应用的功能被拆解成大量独立、细粒度的服务。而且对于一个应用来说,一个微服务就是一个可独立发布的应用;对于一个团队来说,为各个部门,不同岗位提供更多协同与沟通上的思路。
像蓝凌MK-PaaS平台,采用SpringCloud微服务架构,升级更灵活,容错能力强;滚动升级,应用/服务高可用;业务模块支撑可拆可合部署߅支持分布式、容器化部署,大并发、大数据量下性能有保障。前后端分离,前端技术采用react技术栈,具备更好跨平台特性,在前端页面表现、速度流畅、兼容性等多方面提供极致用户体验。

更多文章:
avantage怎么设置为中文(Avantage安装丢失GIT)
2026年10月15日 03:00
activex控件未注册怎么办(登陆视频监控网页时提示activex控件未注册,怎么解决)
2026年10月14日 20:30
excel连接sql数据库教程(excel怎么连接sql数据库)
2026年10月14日 19:40






