大型互联网公司微服务架构的大型互联网公司微服务架构的10个核心问题个核心问题
微服务最近非常流行,各大互联网公司纷纷采用微服务架构体系,微服务架构模式正在为敏捷部署以及复杂企业应用实施提供
巨大的帮助。
本文受中国Java开发者大会组委会邀约编撰而成,让大家10分钟了解微服务。
1 什么是微服务?
微服务架构我们没有一个明确的定义,但简单来说微服务架构是: 采用一组服务的方式来构建一个应用,服务独立部署在不
同的进程中,不同服务通过一些轻量级交互机制来通信,例如 RPC、HTTP 等,服务可独立扩展伸缩,每个服务定义了明确
的边界,不同的服务甚至可以采用不同的编程语言来实现,由独立的团队来维护。
2 微服务架构有哪些特征(Characteristics)?
1. 通过服务实现组件化
传统实现组件的方式是通过库(library),传统组件是和应用一起运行在进程中,组件的局部变化意味着整个应用的重新部
署。 通过服务来实现组件,意味着将应用拆散为一系列的服务运行在不同的进程中,那么单一服务的局部变化只需重新部署
对应的服务进程。 另外将服务作为组件可以更明确的定义出组件的边界。
2. 按业务能力来划分服务与组织团队
康威定律(Conway's law)指出:
organizations which design systems ... are constrained to produce designs which are copies of the communication
structures of these organizations.
任何设计系统的组织,最终产生的设计等同于组织之内、之间的沟通结构。
传统开发方式中,我们将工程师按技能专长分层为前端层、中间层、数据层,前端对应的角色为UI、页面构建师等,中间层对
应的角色为服务端业务开发工程师,数据层对应着DBA等角色。 事实上传统应用设计架构的分层结构正反应了不同角色的沟
通结构。 而微服务架构的开发模式不同于传统方式,它将应用按业务能力来划分为不同的服务,每个服务都要求在对应业务
领域的全栈(从前端到后端)软件实现,从界面到数据存储到外部沟通协作等等。 因此团队的组织是跨功能的,包含实现业
务所需的全面的技能。 近年兴起的全栈工程师正是因为架构和开发模式的转变而出现,当然具备全栈的工程师其实很少,但
将不同领域的工程师组织为一个全栈的团队就容易的多。
3. 服务即产品
传统的应用开发都是基于项目模式的,开发团队根据一堆功能列表开发出一个软件应用并交付给客户后,该软件应用就进入维
护模式,由另一个维护团队负责,开发团队的职责结束。 而微服务架构的倡导者提议避免采用这种项目模式,更倾向于让开
发团队负责整个产品的全部生命周期。Amazon 对此提出了一个观点:
You buidl it, you run it.
开发团队对软件在生产环境的运行负全部责任,让服务的开发者与服务的使用者(客户)形成每天的交流反馈,来自直接客户
端的反馈有助于开发者提升服务的质量。