一分钟了解微服务的好处与陷阱_第1页
一分钟了解微服务的好处与陷阱_第2页
全文预览已结束

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

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 示例项目为贯穿, 结合实际 工程应用案例, 帮助学员快

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论