微服务0-概述

微服务就是功能完善的一小块，项目组的架构很特别，dao是一个微服务，service是一个微服务，单个微也功能完善，可以单独启动。因为它的数据在service处理完都用文件缓存，service只能调用service，但怎么反驳这个架构，诸位。为了做到知行合一，我得先知。

开篇-概述

1. 单体应用的问题

复杂性：模块边界模糊 ，依赖关系不清
部署频率低：全量部署，影响范围大，风险高，耗时长。频率低则改动太多，出错率高。
可靠性差：一个bug,eg死循环,OOM等等导致整个应用崩溃。
扩展能力： 作为整体进行扩展，无法根据业务模块的需要进行扩展。计算密集型需要强劲CPU,IO密集型需要更大内存。
阻碍技术从创新

2. 微服务特点

1. 独立进程。
2. 每个服务微独立的业务开发，一个微服务只关注特定的功能。（公司项目不满足）
3. 通过一些清凉的通信机制进行通信。
4. 全自动部署。（不满足）

3. 微服务优缺点

优点：

易于开发维护
技术栈不受限
按需伸缩

缺点：

运维要求高
分布式固有的复杂性：系统容错，网络延迟，分布式事务。
接口调整成本高
重复劳动

微服务设计原则

• 单一职责原则
• 服务自治原则
• 轻量级通信机制 REST, AMQP, STOMP, MQTT
• 微服务粒度 领域驱动设计: 软件核心复杂性应对之道 和 康威定律:综合考量团队的现状

如何实现微服务架构

自动化部署工具IaaS,Paas,Caas
开发框架：

• Spring Cloud: 优点是开箱即用，文档丰富， 社区活跃， 并提供了完整的解决方案。其它的还有Dubbo, Dropwizard, Armada等

运行平台：可以部署在PC Server，或者阿里云，AWS等云计算平台都是可以。出于轻量/灵活/应用支撑等方面的考虑。后面都是用Docker(啥玩意儿，前面都没说）