什么是微服务

微服务采用一组服务的方式来构建一个应用,服务独立部署在不同的进程中,不同服务通过一些轻量级交互机制来通信,例如 RPC、HTTP 等,服务可独立扩展伸缩,每个服务定义了明确的边界,不同的服务甚至可以采用不同的编程语言来实现,由独立的团队来维护。

微服务架构特征(Characteristics)

1.通过服务实现组件化

传统实现组件的方式是通过库(library),传统组件是和应用一起运行在进程中,组件的局部变化意味着整个应用的重新部署。 通过服务来实现组件,意味着将应用拆散为一系列的服务运行在不同的进程中,那么单一服务的局部变化只需重新部署对应的服务进程。 另外将服务作为组件可以更明确的定义出组件的边界,因为服务之间的调用是跨进程的,清晰的边界和职责定义是设计时必须考虑的。

2.按业务能力来划分服务与组织团队

传统开发方式中,我们将工程师按技能专长分层为前端层、中间层、数据层,前端对应的角色为UI、页面构建师等,中间层对应的角色为服务端业务开发工程师, 数据层对应着DBA等角色。 事实上传统应用设计架构的分层结构正反应了不同角色的沟通结构。 而微服务架构的开发模式不同于传统方式,它将应用按业务能力来划分为不同的服务,每个服务都要求在对应业务领域的全栈(从前端到后端)软件实现,从界面到 数据存储到外部沟通协作等等。 因此团队的组织是跨功能的,包含实现业务所需的全面的技能。 近年兴起的全栈工程师正是因为架构和开发模式的转变而出现,当然具备全栈的工程师其实很少,但将不同领域的工程师组织为一个全栈的团队就容易的多。

3.服务即产品

传统的应用开发都是基于项目模式的,开发团队根据一堆功能列表开发出一个软件应用并交付给客户后,该软件应用就进入维护模式,由 另一个维护团队负责,开发团队的职责结束。 而微服务架构的倡导者提议避免采用这种项目模式,更倾向于让开发团队负责整个产品的全部生命周期。

4.智能终端与哑管道

微服务架构抛弃了 ESB 过度复杂的业务规则编排、消息路由等。 服务作为智能终端,所有的业务智能逻辑在服务内部处理,而服务间的通信尽可能的轻量化,不添加任何额外的业务规则。

5.去中心统一化

传统应用中倾向采用统一的技术平台或产品来解决所有问题。 不是每个问题都是钉子,也不是每个解决方案都是一个锤子。 问题有其具体性,解决方案也应有其针对性。 用最适合的技术方案去解决具体的问题,在大一统的传统应用中其实很难做到,而微服务的架构意味着,你可以针对不同的业务服务特征选择不同的技术平台或产 品,有针对性的解决具体的业务问题。

6.基础设施自动化

单一进程的传统应用被拆分为一系列的多进程服务后,意味着开发、调试、测试、集成、监控和发布的复杂度都会相应增大。 必须要有合适的自动化基础设施来支持微服务架构模式,否则开发、运维成本将大大增加。

7.Design for failure

正因为将服务独立在不同的进程中后,引入了额外的失败因素。 任何时刻对服务的调用都可能因为服务方不可用导致失败,这就要求服务的消费方需要优雅的处理此类错误。 这其实是相对传统应用开发方式的一个缺点,不过随着一些开源服务化框架的出现,对业务开发人员而言适当的屏蔽了类似的错误处理,不过开发人员依然需要知道 对服务的调用是完全不同于进程内的方法或函数调用的。

8.进化设计

一旦采用了微服务架构模式,那么在服务需要变更时我们要特别小心,服务提供者的变更可能引发服务消费者的兼容性破坏,时刻谨记保持服务契约(接口)的兼容性。