Tagged: Micro Service

0

[转]一个可供中小团队参考的微服务架构技术栈

近年,Spring Cloud 俨然已经成为微服务开发的主流技术栈,在国内开发者社区非常火爆。我近年一直在一线互联网公司(携程,拍拍贷等)开展微服务架构实践,根据我个人的一线实践经验和我平时对 Spring Cloud 的调研,我认为 Spring Cloud 技术栈中的有些组件离生产级开发尚有一定距离。比方说 Spring Cloud Config 和 Spring Cloud Sleuth 都是 Pivotal 自研产品,尚未得到大规模企业级生产应用,很多企业级特性缺失(具体见我后文描述)。 另外 Spring Cloud 体系还缺失一些关键的微服务基础组件,比如 Metrics 监控,健康检查和告警等。所以我在参考 Spring Cloud 微服务技术栈的基础上,结合自身的实战落地经验,也结合国内外一线互联网公司(例如 Netflix,点评,携程,Zalando 等)的开源实践,综合提出更贴近国内技术文化特色的轻量级的微服务参考技术栈。希望这个参考技术栈对一线的架构师(或者是初创公司)有一个好的指导,能够少走弯路,快速落地微服务架构。 Please follow and like...

0

[转]重新理解微服务

微服务是个说的挺长时间的概念,也是比较成熟的技术体系。像 Spring Cloud,甚至提供了微服务所需要的全套框架,包括注册中心 (Eureka)、配置中心 (Config)、断路器 (Hytrix)、API 网关 (Zuul) 等组件。微服务体系庞杂,每个组件都能独自成章。本文作者仅从个人的经验和实践出发,谈了谈自己对微服务及其部分内涵的思考和理解。 作者张轲目前任职于杭州大树网络技术有限公司,担任首席架构师,负责系统整体业务架构以及基础架构,熟悉微服务、分布式设计、中间件领域,对运维、测试、敏捷开发等相关领域也有所涉猎。 Please follow and like us:0

0

[转]权衡取舍:企业落地微服务避坑指南

微服务是一种软件架构风格,以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础,利用模组化的方式组合出复杂的大型应用程序,各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯。在去年,我们更多的还只是听到大家都在谈论微服务这个概念,但是在今年,就已经有很多微服务落地项目了,并且可以越来越多的企业在向微服务架构转型。企业到底要不要转向微服务,又该怎么向微服务转型?关于这些问题,我们采访了 BoCloud 博云高级解决方案架构师赵安全,来看看企业在微服务转型中应该注意什么。 Please follow and like us:0

0

[转]微服务架构技术栈选型手册

一、前言 2014 年可以认为是微服务 1.0 的元年,当年有几个标志性事件,一是 Martin Fowler 在其博客上发表了”Microservices”一文,正式提出微服务架构风格;二是 Netflix 微服务架构经过多年大规模生产验证,最终抽象落地形成一整套开源的微服务基础组件,统称 NetflixOSS,Netflix 的成功经验开始被业界认可并推崇;三是 Pivotal 将 NetflixOSS 开源微服务组件集成到其 Spring 体系,推出 Spring Cloud 微服务开发技术栈。 一晃三年过去,微服务技术生态又发生了巨大变化,容器,PaaS,Cloud Native,gRPC,ServiceMesh,Serverless 等新技术新理念你方唱罢我登场,不知不觉我们又来到了微服务 2.0 时代。 基于近年在微服务基础架构方面的实战经验和平时的学习积累,我想总结并提出一些构建微服务 2.0 技术栈的选型思路,供各位在一线实战的架构师、工程师参考借鉴。对于一些暂时还没有成熟开源产品的微服务支撑模块,我也会给出一些定制自研的设计思路。 二、选型准则 对于技术选型,我个人有很多标准,其中下面三项是最重要的: 1.    生产级...

0

[转]API网关性能比较:NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd

前几天拜读了 OpsGenie 公司(一家致力于 Dev & Ops 的公司)的资深工程师 Turgay Çelik 博士写的一篇文章(链接在文末),文中介绍了他们最初也是采用 Nginx 作为单体应用的网关,后来接触到微服务架构后开始逐渐采用了其他组件。 我对于所做的工作或者感兴趣的技术,喜欢刨根问底,所以当读一篇文章时发现没有看到我想要看到的设计思想,我就会四处搜集资料,此外这篇文章涉及了我正在捣鼓的 Spring Cloud,所以我就决定写一篇文章,争取能从设计思路上解释为什么会有这样的性能差异。 Please follow and like us:0

0

[转]运维能力是微服务架构的先决条件

  今天我们来聊聊微服务架构模式下的一个核心概念:应用。 我会从这几个方面来讲:应用的起源、应用模型和应用关系模型建模以及为什么要这样做。最终希望,在微服务的架构模式下,我们的运维视角一定转到应用这个核心概念上来,一切要从应用的角度来分析和看待问题。 Please follow and like us:0

0

[转]如果潜心研究Netflix微服务技术多年,能学到什么?

写在前面 作者近期针对企业数字化和架构转型思考后陆续写了三篇文章,这篇是第三篇,主题专注微服务和 DevOps 支撑技术,以 Netflix 技术栈为例。第一篇称为《企业的组织架构是如何影响技术架构的》[附录 8],主题是建立背景上下文 (background)。第二篇称为《将你的组织架构旋转 90 度》[附录 9],主题专注组织架构转型。 为啥前面要花两篇讲组织架构背景和转型?因为微服务和 DevOps 在本质上需要组织架构转型 (Re-org),组织架构对了,技术架构才能落地下来。如不考虑组织架构,直接切入技术架构(很多架构师的通病),则失败风险巨大。 为啥要以 Netflix 技术为例?因为 Netflix 是业界微服务和 DevOps 组织的楷模,有大规模生产级微服务的成功实践。而且其技术栈大部分开源,模块化抽象好,整个体系是一个样板。相关技术资料也丰富,可以从其公司的 techblog 或者 slideshare 上直接获得。本文是作者多年研究 Netflix 技术资料的总结,可以认为是对 Netflix 微服务技术架构的一次全面系统的反向工程。 Please follow and like...

0

[转]从既有系统到微服务架构

[Source] 从既有系统到微服务架构 微服务近年来可谓炙手可热,合理的使用微服务架构可以解耦系统、提供更好的软件伸缩性以及提高组织的敏捷性。然而现实中较少有项目一开始就会选择使用微服务架构,绝大多数新项目在最初都会务实地从更容易掌控的单体架构起步构建,如果最终发现单体架构复杂到影响了团队的开发效率及软件的伸缩性等方面时,才会开始考虑逐步将系统往微服务架构做演进。 现实中任何软件架构都是诸多trade-off的结果,想要获得微服务架构所带来的好处也就意味着有能力承担它所带来的的副作用。Martin Fowler就曾在MicroservicePrerequisites一文中指出实施微服务所需要的先决条件,他用“个子是否够高”形象地比喻了微服务所需的技能门槛。 而对于既有系统,还需要一种务实的演进方法和实施策略,使得能够伴随着恰当的代码重构,逐步积累能力和完善基础设施,最终平稳的将其演进到微服务架构。 本文总结了一些从既有系统到微服务演进之路上会遇到的问题和解决策略。文中使用“既有系统”而非“遗留系统”,是因为遗留系统给人一种即将退出生命周期、行将就木的感觉,而我们则希望把精力投入到还有长远商业价值的系统上,通过合理的微服务演进让其具有持续的生命力。 Please follow and like us:0