目前微服务是非常火的架构或者说概念，也是在构建大型互联网项目时采用得架构方式。
1.1、单体架构
单体架构，是指将开发好的项目打成war包，然后发布到tomcat等容器中的应用。
- 应用核心是业务逻辑，由定义服务、域对象和事件的模块完成。围绕着核心的是与外界打交道的适配器。适配器包括数据库访问组件、生产和处理消息的消息组件，以及提供API或者UI访问支持的WEB模块等。
- 尽管也是模块化逻辑，但是最终它还是会打包并部署为单体式应用。具体的格式依赖于应用语言和框架。例如，许多java应用会被打包成war格式，部署在tomcat或者jetty上，而另外一些java应用会被打包成自包含的jar格式，同样，rails和node.js会被打包成层级目录。
- 这种应用开发风格很常见，因为IDE和其它工具都擅长开发一个简单应用，这类应用也很易于调试，只需要简单运行此应用，用selenium连接ui就可以完成端到端测试。单体式应用也易于部署，只需要把打包应用拷贝到服务器，通过在负载均衡器后端运行多个拷贝就可以轻松实现应用扩展。在早期这类应用运行的很好。
1.2、单体架构存在的问题
- 复杂性高:以笔者经手的一个百万行级别的单体应用为例，整个项目包含的模块非常多、模块的边界模糊、依赖关系不清晰、代码质量参差不齐、混乱地堆砌在一起。。。整个项目非常复杂。每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个bug都会带来隐含的缺陷。
- 技术债务:随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。“不坏不修(Not broken,don't fix)”，这在软件开发中非常常见，在单体应用中这种思想更甚。已使用的系统设计或代码难以被修改，因为应用程序中的其他模块可能会以意料之外的方式使用它。
- 部署频率低:随着代码的增多，构建和部署的时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署的频率较低。而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错概率比较高。
- 可靠性差:某个应用bug，例如死循环、oom等，可能会导致整个应用的崩溃。
- 扩展能力受限:单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。例如，应用中有得模块是计算密集型得，它需要更强劲得CPU；有的模块则是IO密集型的，需要更大的内存。由于这些模块部署在一起，不得不再硬件的选择上做出妥协。
-
阻碍技术创新:单体应用往往使用统一的技术平台或方案解决所有的问题，团队中的每个成员都必须使用相同的开发语言和框架，要想引入新架构或新技术平台会非常困难。例如，一个使用Struts 2构建的、有100万行代码的单体应用，如果想要换用Spring Mvc，毫无疑问切换的成本是非常高的。
如何解决以上问题呢? ————使用微服务架构。
1.3、什么是微服务
就目前来看，微服务本身并没有一个严格的定义，每个人对微服务的理解都不同。Martin Fowler在他的博客上是这样描述微服务的。
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.These services are built around business capabilities and independently deployable by fully automated deployment machinery.There is a bare minimum of centralized management of these services,which may be written in different programming languages and use different data storage technologies.
用中文表述就是，微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式管理，服务可用不同的语言开发，使用不同的数据存储技术。
1.4、微服务架构的特征
- 每个微服务可独立运行在自己的进程里。
- 一系列独立运行的微服务共同构建起整个系统。
- 每个服务为独立的业务开发，一个微服务只关注某个特定的功能，例如订单管理、用户管理等。
- 微服务之间通过一些轻量的通信机制进行通信，例如通过Restful Api进行调用。
- 可以使用不同的语言与数据存储技术。
- 全自动的部署机制。
1.5、微服务架构示例
每一个应用功能都使用微服务完成。
Spring Cloud—一、微服务架构
Spring Cloud—二、Spring Cloud简介
Spring Cloud—三、使用Spring Cloud实现微服务
Spring Cloud—四、Spring Cloud快速入门
Spring Cloud—五、注册中心Eureka
Spring Cloud—六、使用Ribbon实现负载均衡
Spring Cloud—七、容错保护:Hystrix
Spring Cloud—八、使用Feign实现声明式的Rest调用
Spring Cloud—九、服务网关Spring Cloud Zuul
Spring Cloud—十、使用Spring Cloud Config统一管理微服务
Spring Cloud—十一、使用Spring Cloud Bus(消息总线)实现自动更新
