Mobabel

Just One Pure ITer

Tagged: Micro Service

0

MS Design Princinple

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

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

0

MS Design Princinple

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

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