单体架构

所有代码都跑在一起tomcat ，代码量达到一个数量级基本上启动一次就的等20-30分钟。

微服务架构

服务和服务直接需要保证独立(完全可以独立运行）,这样完全可以在不同的配置机器上来启动微服务。硬件资源分配可以很灵活的分配

微服务缺点：

1、维护成本高

以前维护一个war包现在可能1000个

2、定位问题

3、分布式部署复杂性

4、容错

5、网络延迟

6、接口调整成本高

当A服务调用B服务，但是B服务的接口已经改变很大，这样就导致A调用的代码需要大量更改，除了影响本身还有可能影响其它服务

7、重复劳动

当A服务器写了一个工具，B服务器也写了一个相同的工具，这样就可能浪费(同一种技术栈不存在)

设计原则：
1、单一责任原则（Single Responsibility Principle，SRP）：对于一个微服务而言具有有限的和关注的业务范围可以帮助我们满足服务开发和交付的敏捷性；

2、在微服务的设计阶段，我们应该找到他们的边界，并将它们与业务能力相关联（在领域驱动设计里这叫有边界的上下文）；

3、必须保证微服务设计能支持服务的敏捷/独立地开发和部署；

4、我们应该关注微服务的范围，而不是一味的把服务做小。一个服务的（正确的）大小应该等于满足某个特定业务能力所需要的大小；

5、与SOA里面的服务不同，一个给定的微服务应该有相当少的运营和功能点，以及简单的消息格式；

6、通常一个好的实践是先从一个比较大的服务边界开始，然后随着时间推移基于业务需求来重构成更小的。