微服务基础概念

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

1、Monolithic单体式架构简介

Monolithic单体式架构指的是尽管是模块化逻辑，但是最终还是会打包并部署为一个单一应用。

2、Monolithic单体式架构的优缺点

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

3、单体式架构面临的挑战

4、微服务架构模式倡导的做法

提倡将monolithic单体式架构应用划分为一系列小的服务，服务之间相互协调、相互配合，为用户提供服务。  

5、想微服务架构演进的推荐顺序

规划——中间件和数据库——服务和应用

6、微服务架构的优点

每个服务足够内聚，代码容易理解，开发效率高，服务之间可独立部署，使得持续部署成为可能。

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

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

12-Factor

2、“12-Factor”方法论

提供相应的方法论，使用标准化流程，自动配置，从而使新的开发者花费最少的学习成本加入这个项目，和操作系统之间尽可能的划清界限，在各个系统中提供做大的可移植性。适合部署在现在的云计算平台，从而在服务器和系统管理方面节省资源。将开发环境和生产环境的差异降至最低。并使用持续交付，实施敏捷开发。可以在工具、架构和开发流程不发生明显变化的前提下实施扩展。

3、基准代码

基准代码和应用之间总是保持一一对应的关系。

一旦有多个基准代码，就不能称之为一个应用，而是一个分布式系统。分布式系统中的每一个组件都是一个应用，每一个应用可以分别使用12-Factor进行开发。

多个应用共享一份基准代码有悖于12-Factor原则。解决方案是将共享的代码拆分为独立的类库，然后使用以来管理策略去加载它们。

4、依赖关系

应用程序不会隐式依赖系统级的类库。它一定通过依赖清单，确切的声明所有依赖项。

此外，在运行过程中通过依赖隔离工具来确保程序不会调用系统中存在但清单中未声明的依赖项。

5、配制

环境变量可以非常方便的在不同的部署间做修改，却不动一行代码。

与配置文件不同，不小心把他们签入代码库的概率微乎其微。

与一些传统的解决配制问题的机制（比如Java的属性配制文件）相比，环境变量与语言和系统无关。

6、后端服务

12-Factor应用不会区别对待本地或第三方服务。对应用程序而言，两个都是附加资源。

12-Factor应用支持任意部署。如，可以在不进行任何代码改动的情况下，将本地的MySQL数据库换成第三方服务。