大概从16年开始，微服务的概念快速升温，基本上人人在谈。微服务来源于对SOA（Services Oriented Architecture）的优化重塑。经过这几年的发展微服务在敏捷开发和复杂的企业级应用开发中的基本上是事实标准。

现在的软件项目不再新开发巨大的单体应用，转而开发众多敏捷轻巧的小应用，共同完成一个大的目标。微服务就是这样一种应用拆分方案的技术落地。

从上图看到，每个微服务都有自己的业务层和数据库层。相互之间完全独立。彼此之间需要采用某种协议进行交互，常见的是HTTP、REST、Dubbo，甚至于使用消息系统交互

原则

1，单一职能原则

这个原则很熟了，在面向对象设计中就经常提到。一个方法，一个类，一个微服务都应该仅负责一件事。

2，围绕业务能力构建

微服务算是一种面向业务的服务架构设计。首先要做的是业务模块的拆解。

微服务的理念是一切为了业务服务。每个微服务要根据自己解决的业务特性而选择合适的技术栈。

这一点上和以前的单体应用有很大不同。在单体应用上，我们通常要考虑各个业务场景的限制，而选择一些能见过不能场景的这种方案。

3，持续运维

一个微服务开发完成后，会由开发团队长期进行后续的运维优化工作。

4，基础设施的自动化

5，应对故障

微服务强调故障应对

微服务强调监控

益处

1，根据业务选择合适的技术栈

2，因为现在的服务都比较小，进行颠覆性改造的成本和难度会小很多

3，服务集群的水平扩展和收缩非常方便

4，服务是自给自足的，所以服务底层平台的切换更容易。究竟是使用公有云，还是自己搭建私有云平台。

5，微服务可以方便的添加新功能，称为一个有机的系统（可以随着时间自己成长）

6，随着技术的发展演进，我们可以将一个微服务升级应用新的技术，而不需要升级整个系统，和前面的有点重复

7，在一个微服务中，可以有多个版本的某一服务

8，可以根据服务的边界，确定团队。在组织划分上便于打造小而专的团队

总结

架构选择的优劣只有在系统使用几年后才能真正显现出来

并不是说以前的单体架构就一无是处，通过真确的业务理解，优秀的设计，专业的开发人员。单体应用一样可以支撑业务

同样，对于微服务架构，一个蹩脚的架构设计，一样会导致低劣的产品出来。要知道，微服务各个组件之间的交互是很复杂的，难以管理和控制。

所以，是一个好的设计+优秀的团队带来优秀的产品。

我建议先从单体架构开始设计一个应用，但单体应用过于复杂，可以尝试拆分微服务。