微服务理论：面向微服务架构与传统架构、SOA对比，及云化对比一、Monolith网上对Microservice进行

一、Monolith网上对Microservice进行介绍的文章常常以Monolith作为开头，我也不会例外。原因是，知道了Monolith的不便之后才能更容易地理解Microservice架构模式所具有的各种优点。
首先请回想一下我们所开发的服务是什么样子的。通常情况下，这个服务所对应的代码由多个项目所组成，各个项目会根据自身所提供功能的不同具有一个明确的边界。在编译时，这些项目将被打包成为一个个JAR包，并最终合并在一起形成一个WAR包。接下来，我们需要将该WAR包上传到Web容器中，解压该WAR包，并重新启动服务器。在执行完这一系列操作之后，我们对服务的编译及部署就已经完成了：
文章插图
这种将所有的代码及功能都包含在一个WAR包中的项目组织方式被称为Monolith 。在项目较小的情况下，这种代码组织方式还是可以接受的：更改完代码后，软件开发人员可以趁着编译器编译代码的时候冲杯咖啡，并在回到座位后花费一分钟部署刚刚编译出来的WAR包以便测试自己刚刚所做的更改。但随着项目的逐渐变大，整个开发流程的时间也会变得很长：即使在仅仅更改了一行代码的情况下，软件开发人员需要花费几十分钟甚至超过一个小时的时间对所有代码进行编译，并接下来花费大量的时间重新部署刚刚生成的产品，以验证自己的更改是否正确。
如果应用的部署非常麻烦，那么为了对自己的更改进行测试，软件开发人员还需要在部署前进行大量的环境设置，进而使得软件开发人员的工作变得繁杂而无趣：
文章插图
从上面的示意图中可以看到，在应用变大之后，软件开发人员花在编译及部署的时间明显增多，甚至超过了他对代码进行更改并测试的时间，效率已经变得十分低下。
在变得越来越大的同时，我们的应用所使用的技术也会变得越来越多。这些技术有些是不兼容的，就比如在一个项目中大范围地混合使用C++和Java几乎是不可能的事情。在这种情况下，我们就需要抛弃对某些不兼容技术的使用，而选择一种不是那么适合的技术来实现特定的功能。
除此之外，由于按照Monolith组织的代码将只产生一个包含了所有功能的WAR包，因此在对服务的容量进行扩展的时候，我们只能选择重复地部署这些WAR包来扩展服务能力，而不是仅仅扩展出现系统瓶颈的组成：
文章插图
但是这种扩展方式极大地浪费了资源。就以上图所展示的情况为例：在一个服务中，某个组成的负载已经达到了90% ，也就是到了不得不对服务能力进行扩容的时候了。而同一服务的其它三个组成的负载还没有到其处理能力的20% 。由于Monolith服务中的各个组成是打包在同一个WAR包中的，因此通过添加一个额外的服务实例虽然可以将需要扩容的组成的负载降低到了45% ，但是也使得其它各组成的利用率更为低下。
可以说，所有的不便都是由于Monolith服务中一个WAR包包含了该服务的所有功能所导致的。而解决该问题的方法就是Microservice架构模式。
传统应用架构传统的企业级应用是单体应用（monolith application），一般是分层结构，如表现层/应用层/领域层/数据层，这主要是水平切分的思想。
【微服务理论：面向微服务架构与传统架构、SOA对比，及云化对比】随着互联网应用的发展，特别是大型电商系统，业务非常复杂。这种巨型系统，首先要关注的是如何根据业务划分子系统，然后是子系统间如何协作，最后才是子系统内部实现。 SOA设计可以很有效支持前面两步，在SOA体系里，每个子系统是独立的服务，服务接口体现子系统协作关系，至于子系统内部，直接作为黑盒子处理。
所以对于复杂系统，首先采用SOA垂直切分子系统，然后使用分层设计水平切分单个子系统，服务化把传统的分层设计往前更推进一步。
当然SOA本身也在不断发展，最初跨企业的Web service交互可认为1.0时代；支持企业内部系统间轻量级访问，支持服务治理，可认为2.0时代；服务进一步分层和微服务化可认为3.0时代。
Web应用程序发展的早期，大部分Web工程是将所有的功能模块（service side）打包到一起并放在一个web容器中运行，很多企业的Java应用程序打包为war包。其他语言（Ruby ， Python或者C++）写的程序也有类似的情况[5] 。