一分钟了解微服务的好处与陷阱

上传人:工**** 文档编号:509887909 上传时间:2024-01-14 格式:DOC 页数:4 大小:17KB
返回 下载 相关 举报
一分钟了解微服务的好处与陷阱_第1页
第1页 / 共4页
一分钟了解微服务的好处与陷阱_第2页
第2页 / 共4页
一分钟了解微服务的好处与陷阱_第3页
第3页 / 共4页
一分钟了解微服务的好处与陷阱_第4页
第4页 / 共4页
亲,该文档总共4页,全部预览完了,如果喜欢就下载吧!
资源描述

《一分钟了解微服务的好处与陷阱》由会员分享,可在线阅读,更多相关《一分钟了解微服务的好处与陷阱(4页珍藏版)》请在金锄头文库上搜索。

1、一分钟了解微服务的好处与陷阱写在前面 微服务架构设计风格代表了下一代的架构设 计思想,配合现在的容器工具(如 Docker ),可以在软件开 发流程、部署、服务维护等各方面产生新的生产效率提升; 通过微服务可以更好地体现业务逻辑、更快地交付软件,并 且借助 IAAS 平台,能够快速地扩展服务支撑更大的访问流 量压力。 但是不一定所有的业务场景都适合微服务,有时 候非常简单的业务场景下,微服务反而会降低效率。尤其是 我们在使用微服务架构时,明确其提供的能力以外,也需要 明确背后的代价,比如: 什么是微服务 微服务是一种软件 架构风格,它是以专注于单一责任与功能的小型功能区块为 基础,利用模组化的

2、方式组合出复杂的大型应用程序,各功 能区块使用与语言无关的 API (例如 REST )集相互通讯, 且每个服务可以被单独部署,在微服务软件架构风格概念被 提出来的初期, 它具备以下三个核心特点: 1. 微服务为大型 系统而生。 通常我们在系统架构设计上面临的问题都与系 统的大小相关,随着业务的快速增长,会带来系统流量压力 和复杂度的上升,系统的可维护性和可扩展性成为架构设计 的主要考虑因素,微服务架构设计理念通过小而美的业务拆 分,通过分而自治来实现复杂系统的优雅设计实现。 2. 微服 务架构是面向结果的。 微服务架构设计风格的产生并非是 出于学术或为标准而标准的设计,而是在软件架构设计领域

3、 不断演进过程中,面对实际工业界所遇到问题,而出现的面 向解决实际问题的架构设计风格。 3. 专注于服务的可替代性 来设计。 微服务架构设计风格核心要解决的问题之一便是 如何便利地在大型系统中进行系统组件的维护和替换,且不 影响整体系统稳定性。 微服务的特征 每个微服务仅对单个 业务负责,且为该业务的容量负责;每个微服务可以进行独 立部署, 即不需要依赖其它微服务及其相关资源, 如数据库、 内存缓存系统等; 轻量级的通信协议, 例如 REST 、STOMP 、 AMQP 等;服务的可替代性,代表着每个微服务原则上都可 以使用不同的语言、框架进行技术实现,且更换实现后的微 服务对于整个业务系统不

4、会造成影响;每个微服务拥有单独 的数据存储;每个微服务由小团队维护,服务以业务来进行 拆分后,每个微服务的维护工作将有人数不多的小团队进行 维护。 微服务带来的好处 独立的可扩展性,每个微服务都 可以独立进行横向或纵向扩展,根据业务实际增长情况来进 行快速扩展;独立的可升级性,每个微服务都可以独立进行 服务升级、更新,不用依赖于其它服务,结合持续集成工具 可以进行持续发布,开发人员就可以独立快速完成服务升级 发布流程;易维护性,每个微服务的代码均只专注于完成该 单个业务范畴的事情,因此微服务项目代码数量将减少至 IDE 可以快速加载的大小,这样可以提高了代码的可读性, 进而可以提高研发人员的生

5、产效率;语言无关性,研发人员 可以选用自己最为熟悉的语言和框架来完成他们的微服务 项目(当然,一般根据每个公司的实际技术栈需要来了) , 这样在面对新技术或新框架的选用时,微服务能够更好地进 行快速响应;故障和资源的隔离性,在系统中出现不好的资 源操作行为时,例如内存泄露、数据库连接未关闭等情况, 将仅仅只会影响单个微服务;优化跨团队沟通,如果要完全 实践微服务架构设计风格,研发团队势必会按照新的原则来 进行划分,由之前的按照技能、职能划分的方式变为按照业 务(单个微服务)来进行划分,如此这般团队里将有各个方 向技能的研发人员,沟通效率上来说要优于之前按照技能进 行划分的组织架构;原生基于“云

6、”的系统架构设计,基于微 服务架构设计风格,我们能构建出来原生对于“云”具备超高 友好度的系统,与常用容器工具如 Docker 能够很方便地结 合,构建持续发布系统与 IaaS 、PaaS 平台对接,使其能够 方便的部署于各类“云”上,如公用云、 私有云以及混合云。 避 免微服务的陷阱 不要以微服务作为开始,在项目刚开始时, 一般都还很小,不需要进行非常完整的业务拆分,如果采用 “微服务”作为开始会有点杀鸡用牛刀的感觉,当然,你的项 目非常之庞大的话,以“微服务”为始是个不错的选择;不要 自己进行基础设施的管理,微服务意味着一堆的数据库、消 息系统、数据缓存系统等,会带来相应的运维管理成本(这

7、 里的前提是,没有良好的自动化运维平台和工具) ,建议多 使用 IaaS 、 PaaS 平台,部署发布与其对接;无 DevOps 、 不微服务,如果研发团队不具备 DevOps 的理念并贯彻执行, 仅想单独来实施微服务的话,在实施过程中会发现比之前的 架构维护要困难些,主要原因是微服务需要持续集成、持续 部署及监控等工具或系统的配合才能降低其带来的维护成 本;不要创建过多的微服务,微服务的业务颗粒度一定要根 据实际业务系统的现状及日后规划来制定,切记不要制定过 细的拆分颗粒度; 可能带来的延迟问题, 由于服务拆分开来, 部署到不同的平台或网络,可能会引起微服务间的调用延迟 问题,服务间的调用延迟可能带来整体系统的响应缓慢问题; 微服务不是银弹。 写在最后 此外,微服务的设计模式,微 服务的测试与部署,这些实战都需要就具体业务场景展开, 这里推荐一个特别牛的课程。 跟我做一个 Java 微服务实 战项目 授课专家:刘俊强,迅雷技术总监,极客邦 EGO 会 员学习内容: 以在线商城 eMall 示例项目为贯穿, 结合实际 工程应用案例, 帮助学员快速掌握 Java 微服务架构实践的 核心技能和应用思想。学习周期: 8 周系统学习学习时间: 每周四晚 21:00-22:00 上课学习形式:直播视频授课课程价 格: 1699 元开班时间: 2 月 15 日扫描下方二维码报名学习 课程!

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 商业/管理/HR > 商业计划书

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号