0%

浅谈微服务架构

单块应用

所有功能都揉于一个容器中,可以简单有效的配合事务做到业务数据的ACID,但是内部相互之间依赖关系较复杂,耦合度较高,存在不易拆解、不易扩展、不灵活等弊端

微服务关键设计原则

  • 微服务是一系列根据业务流程拆分出来的业务单元
  • 它们是一系列包含了业务逻辑并能采用简单信道和协议与之进行通信的智能端点
  • 根据设计,微服务架构是去中心化的,旨在构建强壮,弹性的系统应用

关键好处

  • 弹性。系统处理变化的能力。
  • 可伸缩性。对某个微服务单独做cluster应付高负载强计算而不牵动其他模块。
  • 技术多样性。秉承高内聚,低耦合的原则,每个微服务对外暴露接口,但内部实现完全透明,也就是内部说可以用nodejs、erlang、golang等等语言实现。
  • 可替换性。指替换系统中某个模块而不影响系统的能力。有利于减少解决技术债务
  • 独立性。小而独立,分而治之。
  • 易于部署。微服务是自治的工作单元,可单独部署与升级。

SOA

面向服务架构,这也是一种软件设计原则。大体上,SOA与微服务架构是非常想想的。那么他们之间的区别是什么呢?

  • 微服务是细粒度的SOA组件,它们是关注点更窄的轻量级服务
  • 推崇执行标准不同。SOA未推崇,以J2EE技术栈中的ESB举例;而微服务推崇使用http
  • 领域模型。在微服务架构中,每个微服务通常自治数据库,并且隔离领域模型;而在SOA架构中各业务组件通常IO同一个大型数据库,并且业务组件之间共享领域模型。

模块化的基本原则(SOLID)

‘use strict’

  • 单一职责原则。尽可能的只处理某一范围的逻辑功能,如字符串操作、二次封装的http请求模块
  • 开放封闭原则。对功能扩展开放,对修改公用代码关闭
  • 理氏替换原则。
  • 接口分离原则。JS与C#、Java不同,它不是一门面向接口的语言。但是可通过module.exports变量将公用函数暴露给其他模块使用。
  • 依赖倒置原则(反转控制和依赖注入)。依赖倒置指模块间应依赖于抽象,反转控制指创建某个类实例的逻辑移交给某IoC容器控制,依赖注入指在IoC容器中对类实例配置所需依赖的操作。

服务器DevOps工具

  • chef. infrastructure automation
  • inspec. compliance automation
  • habitat. application automation