微服务

单体架构的痛点
缺点一：项目过于臃肿

当大大小小的功能模块都集中在同一项目的时候，整个项目必然会变得臃肿，让开发者难以维护。

缺点二：资源无法隔离

整个单体系统的各个功能模块都依赖于同样的数据库、内存等资源，一旦某个功能模块对资源使用不当，整个系统都会被拖垮。且多个模块共用一个jvm进程，进程资源紧张

缺点三：无法灵活扩展
当系统的访问量越来越大的时候，单体系统固然可以进行水平扩展，部署在多台机器上组成集群：

但是这种扩展并非灵活的扩展。比如我们现在的性能瓶颈是支付模块，希望只针对支付模块做水平扩展，这一点在单体系统是做不到的。

微服务架构

什么是微服务？
微服务（Microservice Architecture）是近几年流行的一种架构思想，关于它的概念很难一言以蔽之。
究竟什么是微服务呢？我们在此引用 ThoughtWorks 公司的首席科学家 Martin Fowler 的一段话：

简而言之，微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。 
这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。 
这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。

自己理解：
简单说就是将一个完整的应用（单体应用）按照一定的拆分规则拆分成多个不同的服务，每个服务都能独立地进行开发、部署、扩展。服务于服务之间通过注入RESTful api或其他方式调用。

微服务有什么样的具体特点呢？

1.独立部署，灵活扩展

2.资源的有效隔离

3.团队组织架构的调整

微服务与面向服务架构SOA的区别

SOA架构强调的是异构系统之间的通信和解耦合，是一种粗粒度的拆分。而微服务架构强调的是系统按业务边界做细粒度的拆分和部署。

微服务架构的不足

1.分布式固有的缺点：
如准守cap/base理论，

2.分区的数据库架构

可能会涉及到分布式事务

同时更新多个业务主体的事务很普遍。这种事务对于单体式应用来说很容易，因为只有一个数据库。
在微服务架构应用中，需要更新不同服务所使用的不同的数据库。使用分布式事务并不一定是好的选择，不仅仅是因为 CAP 理论，还因为当前高扩展性的 NoSQL 数据库和消息传递中间件并不支持这一需求。
最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。

3.服务之间的依赖关系

4.部署变复杂

参考资料：
1.漫画：什么是微服务？https://blog.csdn.net/bjweimengshu/article/details/79061742
2.微服务架构的优势与不足https://blog.csdn.net/albenxie/article/details/73478306