SpringBoot番外篇-微服务架构【1.起源与定义】

什么是微服务？

微服务就是用一组小服务的方式来构建一个应用，服务独立运行在不同的进程中，服务之间通过轻量的通讯机制（如 RESTful 接口）来交互，并且服务可以通过自动化部署方式独立部署。

---

背景
Docker容器技术的发展有效解决了服务粒度细、服务数量多所导致的开发环境搭建、部署、运维成本高的问题。敏捷、精益、持续交付、DevOps是微服务的催化剂，起到了推动作用。

---

微服务架构有哪些特征？

1. 服务实现组件化
2. 按业务组织团队
3. 关注产品而非项目
4. 技术多样性
5. 去中心统一化，业务独立
6. 基础设施自动化
7. 演进式架构

---

为什么要使用微服务架构？

单体式应用：

1. 系统复杂，耦合度高，开发水平不一导致性能低下[不利于持续开发]；
2. 运维困难[不利于持续部署]；
3. 无法扩展[采用新架构和语言非常困难]；
4. 不可靠[一个内存泄露有可能弄垮整个进程、应用]；

微服务架构：
API Gateway-[负载均衡，缓存，路由，访问控制，服务代理，监控，日志等]；
API GW / API 网关，顾名思义，是出现在系统边界上的一个面向 API 的、串行集中式的强管控服务，这里的边界是企业 IT 系统的边界，主要起到隔离外部访问与内部系统的作用。

Scala Cube 3D模型[X轴由负载均衡器后端运行的多个应用副本组成，Y轴代表将应用分为微服务，Z轴是将需求路由到相关服务];

每种服务都有自己的数据库，每种服务可以用更适合自己的数据库类型，也被称作多语言一致性架构。比如，驾驶员管理（发现哪个驾驶员更靠近乘客），必须使用支持地理信息查询的数据库。

总结
单体式的架构更适合轻量级的简单应用。如果你用它来开发复杂应用，就会出现上面描述的不足。
微服务架构模式可以用来构建复杂应用，当然，这种架构模型也有自己的缺点：微服务应用是分布式系统，由此会带来固有的复杂性；微服务的挑战来自于分区的数据库架构；微服务架构模式应用的改变将会波及多个逻辑相关的服务；测试和部署一个基于微服务架构的应用也是很复杂的任务。

博文推荐
微服务架构：http://www.cnblogs.com/imyalost/p/6792724.html