浅谈单体应用与微服务框架

在我们没有接触到微服务、分布式框架的时候我们所写的程序为单体应用，什么是单体应用呢？
一个归档包（例如war格式或jar格式）包含所有功能的应用程序，通常称为单体应用。而框架单体应用的方法论，就是单体应用框架。
单体应用存在一些问题：

• 复杂性高
• 技术债务
• 部署频率低
• 可靠性差
• 扩展能力受限
• 阻碍技术创新
  综上，随着业务需求的发展，功能的不断增加，单体架构很难满足互联网时代业务快熟变化的需求。

什么是微服务？
微服务本身并没有一个严格的定义，每个人对微服务的理解都不同。（我个人认为，微服务就是根据业务按模块拆分原有的单体应用，然后把每个拆分后的单独部署为单体应用，之间使用rest进行通信调用，应用与应用之间互不影响，耦合性降低，这些单体应用统一管理）Martin Fowle在他的博客中是这样描述微服务的。微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中。服务间通过采用轻量级通讯机制（通常用HTTP资源API）。这些微服务围绕着业务能力构建并且可通过全自动部署机制部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。
微服务特性：

• 每个服务可独立运行在自己的进程里。
• 一系列独立运行的微服务共同构建整个系统。
• 每个服务为单独的业务开发，一个微服务只关注某个特定的功能，例如订单管理、用户管理等。
• 微服务之间通过轻量级的通讯机制进行通信，例如RESTful API进行调用。
• 可以使用不同的语言与数据存储技术。
• 全自动的部署机制。
  微服务的优点：
• 易于开发和维护
• 单个微服务容易部署
• 局部修改容易部署
• 技术栈不受限
• 按需伸缩
  单体应用架构的缺点，恰恰是微服务的优点。
  微服务设计原则
• 单一职责原则
• 服务自治原则
• 轻量级通信机制
• 微服务粒度
  微服务技术选型
  相对于单体应用交付，微服务应用的交付要复杂很多，不仅需要开发框架的支持，还需要一些自动化的部署工具支持。
  下面从开发和运行平台两个维度考虑挑选技术选型。
  开发框架的选择： 可使用SpringCloud作为微服务开发框架。首先，SpringCloud具备开箱即用的生产特性，可大大提升开发效率；再者SpringCloud的文档丰富、社区活跃、遇到问题比较容易获得支持；更为可贵的是SpringCloud为微服务框架提供了完整的解决方案。当然也可以使用Dobbo、Dropwiz-ard、Armada等其他开发框架或解决方案来实现微服务。
  运行平台： 微服务并不绑定运行平台，将微服务部署在PC Server，或者阿里云、腾讯云、AWS等云计算平台都是可以的。如今Docker日渐成熟，直接在Docker中部署微服务即可。
  SpringCloud 微服务架构图：