声明
本一系列文字，摘自 周立《spring cloud 与docker》微服务架构实战一书和方志朋博客
传统单体应用的弊端
一个归档包（war）包含所有功能的程序，通常称为单体应用，它有易部署，测试等优点；然而随着需求的增加，团队人数的增加，代码库的膨胀。慢慢的单体应用变得越来越臃肿，为维护性和灵活性降低维护的成本也越来越高。下面简述了单体应用存在的一些问题
- 高复杂性：由于模块很多，导致模块的边界模糊、依赖关系不清、代码质量参差不齐，修改一个简单的功能或者bug都可能存在隐含的缺陷。
- 技术债务：随着时间推移，需求变更，人员更迭会逐渐形成技术债务，不坏不休，更是常见
- 可靠性差：一个引用的bug会导致整个应用的崩溃
- 部署率低：代码的增多，构建部署的时间也会增加，修改一次功能一个bug都需要重新部署
- 扩展能力有限：只能作为一个整体进行扩展，无法对业务模块进行伸缩（有的高cpu有的高io密集）
- 阻碍技术创新：如struts构建的需要换为spirng mvc 则成本是非常高的
什么是微服务
并没有一个严格的定义，Martin Fowler 在博客中这样描述：微服务架构风格是一种将一个单一的应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务之间采用轻量级的通讯机制通信。这些服务围绕着业务独立部署，并集中式进行管理。
所以微服务具有如下特征
- 每个微服务独立运行在自己的进程里
- 一系列微服务共同构建起整个系统
- 每个微服务独立开发，关注某个特定的功能
- 服务之间采用轻量级通信机制进行通信。例如RESTFul API 进行调用
微服务的优点
- 易于开发和维护，它只关注一个特定的功能，所以它业务清晰，代码量较少
- 局部修改易部署 ，且启动较快
- 技术栈不受限，按需伸缩
微服务设计原则
- 单一原则 应关注整个系统中单独有界限的一部分
- 服务自治 每个服务有独立的业务能力，依赖和运行环境，他们是独立的单元
- 轻量的通信 ，首先本身较轻，其次跨语言平台，像我们熟悉的REST协议，AMQP,STOMP等
- 微服务粒度 这是难点也是焦点，服务间要相对独立和松耦合，结合团队现状综合考虑
微服务面临的挑战
- 运维要求高 ，需要保证几十几百个服务正常协作运作
- 分布式的复杂性 ，系统容错，网络延迟，分布式事务都将面临挑战
- 接口调用成本高，修改了某个服务的api，所有使用了该接口服务都要做调整
- 重复劳动 很多服务需要用到某个功能，而这个功能并没有分解一个微服务的程度，这时候各个服务都需要开发这一功能
什么是spring cloud
- 官网这样描述：Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线）。分布式系统的协调导致了样板模式, 使用Spring Cloud开发人员可以快速地支持实现这些模式的服务和应用程序。他们将在任何分布式环境中运行良好，包括开发人员自己的笔记本电脑，裸机数据中心，以及Cloud Foundry等托管平台
spring cloud 特点
- 约定优于配置，适用各种环境开发，部署
- 隐藏组件的复杂性，提供声明式，无xml 配置方式
- 整合了轻量级的组件 eureka,zuul ,各领域轻量级的实现，组件丰富，功能齐全
- 选型中立，丰富，灵活，支持 eurka,zookeeper, consul 实现服务的发现
spring cloud 版本
- 以 SRX（x为数字）来命名版本号，spring cloud 是一个综合项目，子项目也需要维护自己的版本，这种方式避免与子项目版本混淆。release train、Angel、Brixton、 Camden 等都是伦敦地铁站的名称。他们按照字母顺序发行，进行主版本的演进， SR 表示“ service release” 一般表示bug修复；在SR版本前会先发布一个release 版本。camden SR3 表示3次bug修复版本
spring cloud 兼容性
- Angel 基于spring boot 1.2.x构建，与spring boot 1.3以上不兼容
- Brixton 基于spring boot1.3x 构建，与spring boot 1.2 不兼容
- Camden 基于spring boot 1.4 构建
