微服务到单体架构的演变

单体架构：

      用软件会包括有几百个功能项，而所有这些功能项都打包进了一个单体的应用中。典型的例子有，ERP、CRM等其他各种各样的软件。对于这种野兽级别的软件应用、部署、排错、扩展和升级工作都是一个个噩梦。

 

面向服务的架构（SOA）

     面向服务架构（SOA）设计是针对上述单体架构问题的一个解决方案， 将软件中相似的功能进行分组在一起。在SOA里一个服务的范围是非常广的，由此带来的弊端是服务本身庞大而复杂，数十个功能点，以及复杂的消息格式和标准（例如所有的WS规范）。

       这些服务会随时间越长越大，因为累加的功能越来越多。最后，这些应用本身已变成了单体软件，与传统的单体软件（比如ERP）也没啥两样。

 

单体架构软件的一些特点：

• 单独应用是作为一个整体单元来设计、开发、部署的；

• 单体应用非常复杂，导致的结果就是维护，升级和增加新功能都非常困难；

• 在单体架构下，非常难实践敏捷的开发和部署方法；

• 如果要更新它的某个部署，则需要重新部署整个应用；

• 扩展：必须作为单个软件来扩展，当有资源需求冲突时扩展就变得非常困难（比如一个服务需要更多的CPU但是其他的服务要更多内存）；

• 可靠性：一个不稳定的服务可能会导致整个应用不可用；

• 阻碍创新： 由于所有的功能都基于同一套技术框架来够构建，想加入新的技术或者框架就非常困难。

微服务（Microservices）

     开发一个应用由一组小但是独立的服务来组成，这些服务运行在自己的进程中，可以被独立开发，独立部署。你可能在使用微服务架构从头构建一个软件，也可能是要把已有的应用服务转换为微服务。无论哪种，非常重要的一点都是你必须合理的决定微服务的大小、范围和能力。这极有可能是在实践微服务架构初期碰到的最难的事情。

 

设计原则：

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

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

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

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

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

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

 

参考教程：http://mp.weixin.qq.com/s?__biz=MzA5OTAyNzQ2OA==&mid=2649690838&idx=1&sn=3311478250ddf0b487efb4b1ff0f9b4a&scene=1&srcid=0718JJmHa487XpNrb3jiPRiS#rd