反脆弱性的软件架构 - 微服务

在传统的企业级软件中我们通常有客户端、服务端，在服务端一般分为服务处理、业务逻辑和数据访问等几层。当有新的需求需要加入到软件中时，我们就在各层中加入相应的代码，然后重新测试和部署我们的软件。

当软件体量不大的时候，这样做不会有太大的问题。但是随着软件体量越来越大，要加入更多的功能往往需要花费更多的开发和测试的时间，当有越来越多的用户来使用我们的软件时，增加服务器的数量不能提高软件的性能，要提高软件的性能只能部署内存更多、CPU更强的服务器。几年过后，当技术骨干离开了团队，我们发现很难找到精通我们的软件开发工具的程序员，而要采用新的语言、新的数据库来开发新功能，这几乎是一件不可能的事情。

要知道我们一直使用的是基于精益软件开发模式(Lean Software Development)下的敏捷开发过程啊(Agile Software Development Process)。

前面我们讨论的传统架构我们称它为单体架构(Monolithic Architecture)。在单体架构中，由于每次改动都意味着对整个软件的修改，代价很高，比如每次构建(Build)等上几个小时是很普通的事情。在每个Sprint我们完成的往往只是软件的某几项功能，而不是整个产品，我们只有等到软件的所有功能都完成和测试通过后才能提交和部署我们的产品，完成我们的项目。这需要很多个Sprint。在单体架构下我们的浪费越来越多，提交周期越来越长，越来越做不到精益。

生物都是由细胞组成的。随着生物的生长，细胞会衰老和死亡，但是生物体本身不会死亡。软件为什么不能像生物的细胞那样，用新软件“细胞”来代替衰老的软件“细胞”，让我们的软件生命体始终保持活力而不会付出致命的代价呢？许多迅速成长的公司都遇到了类似的问题。2001年的亚马逊网站就是一个单体架构，虽然它也有很多组件，但是这些组件紧密的耦合在一起，增加新功能的代价十分高昂。亚马逊的解决方案是把这些组件做成一个个微小的Web服务产品，由不同的小组维护，他们说”You build it. You run it.”。这还催生了亚马逊非常成功的AWS云服务业务。NetFlix也采取了在云端使用一个个的微小的Web服务的策略，他们还开源了他们的服务监控工具。亚马逊和NetFlix采用的就是最近几年讨论火热的“微服务”架构。

微服务架构认为软件应该是由一套负责单一业务的微小的服务组成的，每个服务都是被独立部署的产品。为了保证服务技术中立性和松耦合，每个服务采用其他技术重写，通常不能超过2周。这就像生物的细胞一样，单个细胞的死亡和重生不会造成生命体的死亡。微服务是精益化后的SOA架构，它通过限制单一服务的业务范围来提高软件的可重用性从而减少冗余带来的浪费，它通过降低单一服务的规模来降低开发的复杂性，通过运维一体化提高了产品提交的效率。微服务为软件的长期快速演化而生，更为产品开发的敏捷而生。如果你正在开发的系统有本文中提到的问题，你可以现在就开始推动你的软件架构向微服务架构演进吧。

参考：
http://martinfowler.com/articles/microservices.html
http://thenewstack.io/led-amazon-microservices-architecture/
https://www.nginx.com/blog/adopting-microservices-at-netflix-lessons-for-team-and-process-design/