单体架构
单体架构虽然有时候看起来也是模块化的逻辑，但是还是会打包成一个单体应用。其中的最主要的一个问题就是，如果这个应用太复杂，以致于我们的任何单个开发者都不可能搞懂整个应用。这样就会使得应用无法进行一个扩展，可靠性就会极其低下，最终的结果则是我们的敏捷性开发和部署变的特别的困难。
应对的思路：化繁为简，分而治之。
微服务概览
我们常说SOA（面向服务）架构，其实微服务是有一定的关系的，我们 可以认为，微服务是SOA的一种实践。
- 小即是美，小的服务代码量少，bug也少，容易测试，可以快速的迭代和部署。
- 单职责，一个服务只需要做好一件事，专注才能做好。
- 尽可能的创建原型，尽可能早的提供API服务，建立完整的服务契约，达成服务之间的一致性，实现和完善的可以后面慢慢再弄。
- 可移植性比效率更重要。服务之间的轻量级交互协议在效率上和可以执行二者的之间，首先考虑的应该是兼容性和移植性。
微服务每个服务独占一个DB，很多个DB又可以组成集群，理论上单个DB讲无法无限制的扩容，拆分出来之后，他们的之间性能可能会好点。
微服务的定义
微服务指的是围绕业务功能构建的，服务关注单一业务，服务间采用轻量级的通信机制，可以实现全自动独立部署，每个服务之间可以采用不同的编程语言和数据存储计数。通过对业务架构的一个拆分可以实现服务组件化，通过组件组合快速开发系统，业务单一的服务组件可以独立部署，是的整个的系统架构变的清晰灵活。
主要有以下特点：
- 原子服务
- 独立进程
- 隔离部署
- 去中心化的服务治理
缺点：
- 以来于基础设置的建设，同时复杂度高。
未完待续~
