软考架构设计师高分论文（微服务）-Toy模板网

这篇具有很好参考价值的文章主要介绍了软考架构设计师高分论文（微服务）。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

本人于2019年3月参与了某公司的核心项目“在线问诊互联网医院平台”，该平台以在线问诊为核心，分为用户信息管理、病历管理、推荐处方、药品配送等功能。本人在该项目中担任架构师职位，主要负责整体架构设计和技术选型。本文以该项目为例，主要讨论微服务架构设计在项目中的具体应用。首先根据业务领域和技术实现不同，本着单一职责的原则将系统划分众多服务，解决了业务模块高度耦合的难题，其次拆分后的服务利用NACOS进行服务治理来解决服务不好管理，配置文件分散的问题，最后通过Netflix Hystrix实现服务的熔断降级。防止因某个服务异常从而导致雪崩效应，使整条服务链宕机的问题，整个系统历时1年半，于2020年九月上线，至今已稳定运行1年，深受用户好评。

如今信息化时代，信息技术的快速发展以及“互联网+”概念的大力推进，为医疗行业的改革提供了一个新的探索方向，在这样的市场时代背景下，各种数据呈现爆炸式的增长，在线问诊系统开发也开始逐渐流行，也逐渐出现利用计算机辅助诊断的案例，这种模式有效的实现线下患者分流，进一步减轻当前中国医疗健康系统的负担。我司在医疗行业深耕十几载，有良好的医疗基础，又拿下了互联网医院牌照，未来发展有巨大潜能，我司旧系统经过两年时间运行也累计了大量医疗数据，为未来智慧医疗打下坚实的基础，该项目主要以患者问诊，医生接诊为主要功能，凭借问诊效率高，无论身在何处都能为患者提供便捷的优质医疗资源的优势让业务快速扩张，用户量飞速增加，从而也使需求更加快速变化，以前的单体项目显然已逐渐无法适应我司对软件的要求，微服务改造刻不容缓。本项目组全体成员共41人，我在项目中担任系统架构师职务，我主要负责整体架构设计、技术选型、服务拆分等工作。

传统单体架构与微服务架构相比，以往的单体项目所有的功能模块都在一个进程中运行，各模块的之间的耦合度过高，关系十分紧密，基本是单个模块出问题，可能导致整个项目崩溃，各功能模块的扩展性很差，基本对某个功能模块进行扩展，经过调研，我们的系统将采用微服务的架构来进行开发，微服务架构主要有以下特点，1.微服务把每个职责单一的功能放在一个独立的服务中。2.每个服务允许在一个独立的进程中。3.每个服务有自己的数据存储，实际上，每个服务应该有自己独享的数据库、缓存、消息队列等资源。4.每个服务有多个实例在运行，每个实例可以运行在容器化平台内，达到平滑扩展伸缩的效果。5.每个服务应该有自己的运营平台，以及独享的运营人员，这包括技术运维和业务运营人员。每个服务都高度自治，内部的变化对外透明。6.每个服务都可以根据性能需求独立的进行水平伸缩。本文着重从微服务拆分，微服务治理，限流熔断在本项目中的具体应用效果来进行介绍。

一、微服务拆分
通过分析核心业务系统的需求，我们拆分服务秉承一个原则，就是不同微服务的边界明确，不重复开发相同的业务，也就是职责单一原则。并且我们对数据库也进行来拆分，要求每一个服务都有自己的的数据库，不能直接访问其他服务的数据库。每个微服务可以将自己的业务暴露成服务，供其他服务进行调用。最终我们将核心的业务系统拆分为：网关服务、认证中心服务、权限服务、用户中心服务、IM服务、支付服务作为基础服务层。诊疗服务、订单服务、处方服务、病例服务作为业务服务层。定时服务、文件服务、日志服务、分布式事务服务作为工具服务层。每个业务模块都是根据业务领域进行划分，同一个业务领域下因质量属性要求不同需要划分为两个服务，如认证服务和用户服务，由于认证服务是一个比较独立的模块，他只处理用户的登陆登出，作为应用的入口他的可用性和性能的质量属性要求相对较高。用户服务宕机不会影响认证服务。用户可以就登陆系统操作订单，问诊等功能，使我们的系统容错率更高。

二、微服务的治理
由于原单体项目被拆分为众多服务，那服务消费者如何获取服务提供者的具体调用地址，因此引入了Nacos注册中心，每一个服务启动时都需要在注册中心进行服务注册，注册中心会保存这些信息如ip和端口的信息，所以每次服务消费者想要调用某一个服务的时候都可以在注册中心，通过服务名查询到对应服务的IP端口地址，来进行服务访问，服务消费者可以通过负载均衡的算法，从同类型服务列表中选择一个服务来进行远程调用，同时我们要求服务提供者每隔30秒向注册中心发送心跳请求，来确认其健康状态。如果注册中心感知到服务异常就会将其剔除。保证就算有异常服务我们还是能快速发现使其下线，保证系统的可用性，同时对于我们这么多服务的配置文件，我们也采用了nacos的配置中心来进行管理，比较好的一点支持动态配置，在某些功能的切换上面，比如：验证码单日条数的限制，日志的开关，我们都不用让服务重新发版，这也降低了在修改代码和发版过程中人为造成错误的风险。

三、限流熔断
在我们需求分析中，发现诊疗服务，依赖于IM服务、处方服务、订单服务，而处方服务和订单服务又依赖于其他服务，这样下去调用链路很长，也是我们的核心业务，当诊疗服务的链路上有几个调用的子服务宕机或者延迟较高的话，会导致请求被堵住，堵住的请求会消耗掉服务器的资源，当这些请求越来越多，服务来不及处理，慢慢的会导致其他的请求同样无法处理，最后导致整个业务系统卡顿乃至崩溃，调研发现目前最常用的服务依赖保护是熔断和限流，我们通过Hystrix实现了断路器模式，当每个服务节点发生故障之后，通过断路器的故障监控，向调用方，返回一个符合我们预期的备选响应，还不是长时间的等待服务响应，这样保证了服务在整个调用链不会长时间的等待响应，不必要的占用资源，防止故障在整个微服务系统中蔓延，最后乃至雪崩的情况发生。

项目在2020年9月份通过了最终验收，上线，至今以来系统运行也非常稳定，已经连续运行一年多，已有4W以上的医生在平台注册，百万以上的患者得到服务，获得来客户一致的好评，在系统管理上每个服务都有专门的人来管理，提升了产品的体验，也提升了服务客户的质量和效率。同时每次发版也不会对整个系统发版，而是对某个修改的服务发版，面对需求也能快速响应，相比于之前的单体项目，系统逻辑更加清晰，面对日益增加的用户量我们也能通过各个服务的水平扩容来提升系统的负载。但是微服务改造之后，产生了众多服务，运维的开销及成本增加，后续会通过搭建devops平台，运维人员需要写好自动化运维脚本，通过自动化工具可以实现自动发布和监控，可以降低维护成本，提升上线交付效率和质量。

实践证明系统平稳运行与采用来合适的架构风格密不可分，经过此次微服务架构的应用方法，也看到不足之后，在未来还会不断更新知识，完善本系统的架构设计，使整个系统更加合理，更有效的服务于医生和患者。文章来源地址https://www.toymoban.com/news/detail-714853.html