微服务基础概念

从单体架构到微服务架构的演进

Monolithic单体式架构简介:

Monolithic单体式架构指的是尽管是模块化逻辑,但是最终还是会打包并且部署为一个单一应用,具体的格式依赖于具体的语言和框架,例如,部分java应用会被大包围WAR格式,部署在Tomcat上或者JIT上,而另外一些java应用会被打包为自包含的jar格式,同样,Reals和node.js会被打包为层级目录。

Monolithic单体式架构的优缺点:

  • 优点:开发工具IDE和其他工具都擅长开发一个简单应用,这类应用也很易于调试和部署。只需要把打包应用拷贝到服务器端,通过在负载均衡器后端运行多个拷贝,就可以轻松是实现多个扩展
  • 缺点:单体式架构一旦随着时间的推移,逐渐的变大,敏捷开发和部署举步维艰。任何单个开发者都很难搞懂它。修正bug和正确的添加新功能变得非常困难且很耗时。

Monolithic单体式架构面临的挑战:

随着市场变化快用户需求变化快、用户访问量增加的同时,单块架构应用的维护成本、人员的培养成本、缺陷修复成本、技术架构演进的成本、系统扩展成本等都在增加。单块架构的曾经的优势已逐渐不在适应互联网时代的快速变化。

微服务架构模式提倡的做法:

Microservice微服务架构是一种架构模式,提倡将Monolithic单体式架构应用划分为一系列小的服务,服务之间相互协调,相互配合,为用户提供服务。每个服务运行于其独立的进程中,服务之间采用轻量级的协议进行通信,每个服务都围绕着具体业务进行构建,并能够独立部署。

微服务架构的优点

每个服务能够内聚,代码容易理解,开发效率高,服务之间可以独立部署,使得持续部署成为可能,容易正对每个服务组件开发团队,容错性也大大提高。

包括每个服务足够内聚,代码容易理解,开发效率高。

  • 复杂度可控:在将应用分解的同时,规避了原本复杂度无止境的积累。每一个微服务专注于单一功能,并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低,每个微服务可由一个小规模开发团队完全掌控,易于保持高可维护性和开发效率。
  • 独立部署:由于微服务具备独立的运行进程,所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程,使得发布更加高效,同时降低对生产环境所造成的风险,最终缩短应用交付周期。
  • 技术选型灵活:微服务架构下,技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状,自由选择最适合的技术栈。由于每个微服务相对简单,故需要对技术栈进行升级时所面临的风险就较低,甚至完全重构一个微服务也是可行的。
  • 容错:当某一组建发生故障时,在单一进程的传统架构下,故障很有可能在进程内扩散,形成应用全局性的不可用。在微服务架构下,故障会被隔离在单个服务中。若设计良好,其他服务可通过重试、平稳退化等机制实现应用层面的容错。
  • 扩展:单块架构应用也可以实现横向扩展,就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时,微服务架构便体现出其灵活性,因为每个服务可以根据实际需求独立进行扩展。

向微服务架构演进的推荐顺序:

先规划,然后是中间件和数据库,最后是服务和应用。

基于Docker的微服务应用架构设计

微服务架构设计需要遵循的模式:

比较知名的“12-Factor”

  1. 提供了相应的方法论。
  2. 将差异化降到最低。

基准代码:

基准代码和应用之间总是保持一一对应的关系:一但有多个基准代码,就不能称为一个应用,而是一个分布式系统.

多个应用共享一份基准代码是有悖与12-Factor原则。

依赖关系:

  1. 应用程序不会隐式依赖系统级的类库。它一定通过依赖清单,确切地声明所有的依赖项。
  2. 在运行过程中通过依赖隔离工具来确保程序不会调用系统中存在但清单中为申声明的依赖项。
  3. 高层服务可以依赖低层服务,同层服务间不互相依赖。

配置:

  • 环境变量可以非常方便的在不同的部署间做修改,却不动一行代码。
  • 与配置文件不同,不小心把他们嵌入代码库的该类微乎其微。
  • 与一些传统的解决配置问题的机制(比如Java的属性配置文件)相比,环境变量与语言和系统无关。

后端服务:

  • 12-Factor应用不会区别对待第三方服务。对应用程序而言,两种都是附加资源。
  • 12-Factor应用的支持任意部署。如,可以在不进行任何代码改动的情况下,将本地MySQL数据库换成第三方服务。

基于容器的微服务架构剖析

  • Docker比VM虚拟机更加轻量。

  • 每个Docker里面装一个服务或应用,一个服务器上可以运行多个Docker。

  • 每个Docker中运行一个微服务。

  • Docker是一种崭新的PaaS平台。

  • Docker利用容器将资源进行有效隔离。

微服务架构设计模式

  1. 实践微服务需要面临的问题。
  2. 客户端如何访问这些服务。
  3. 服务之间的通信。

微服务云架构管理

微服务简化:

基于容器技术的云服务将极大的简化容器化微服务创建、集成、部署、运维的整个流程,从而推动微服务在云端的大规模实践。

微服务创建:

假设用户的微服务程序,存储与GitHub等代码托管服务中,用户可以将这个代码仓库构建成容器镜像,并保存在镜像仓库中,用户可以将这个微服务一键部署到容器云平台。

云平台提供了持续集成的功能,用户可以选择是否使用。

微服务集成:

用户可以自由组合、复用数以万计的容器化微服务,像搭积木一样轻松集成应用。

比如,用户需要一个通用的MySQL数据库服务,他无需构建镜像,可以直接在镜像仓库中选择合适的数据库服务镜像,并与其微服务连接起来。

微服务部署:

微服务由于组件数量众多,云端部署成为实践上的一个难点。

容器云平台容器为应用发布的载体,用户不必指定传统部署方式助攻繁琐的步骤,只需提供容器镜像和简单的容器配置,平台会将真个部署流程自动化。

微服务运维:

微服务由于独立进程众多,部署后的运维管理成为实践上的另一个难点。

容器云平台完全屏蔽底层云主机和基础架构运维,让用户专注于应用。

通过容器编排、自动修复、自动扩展、监控日志等高级应用生命周期服务,实现容器化微服务的智能托管。

坚持原创技术分享,您的支持将鼓励我继续创作!