互联网技术发展迅速的今天，微服务倍受关注：文章、博客、社交媒体讨论和会议演讲都在谈论。与此同时，也有持怀疑态度的软件社区人员认为微服务没什么新鲜可言。反对者声称它的思想只是面向服务架构的重塑。然而，无论是炒作还是怀疑，不可否认，微服务架构模式具有非常明显的优势 —- 特别是在实施敏捷开发和复杂的企业应用迭代开发方面。
从本篇文章开始，我们来开学了解学习微服务的相关知识。
# 单体应用
我们先不问微服务是什么？微服务该如何实现？让我们从我们原本最熟悉的创建一个应用和一个普通的项目开始说起。
打车系统
我们假设要开始开发一个打车应用，目标是与Uber和DiDi竞争。经过讨论和技术选型，我们开始手动开发生成一个新项目，该新应用有一个模块化的六边形架构，如下图所示：
该应用的核心是由模块实现的业务逻辑。它定义了服务、领域对象和事件。围绕核心的是与外部世界接口对接的适配器。适配器示例包括数据库访问组件、生产和消费消息的消息组件和暴露了 API 或实现了一个 UI 的 web 组件。
- 单体应用：所谓的单体应用就是指一个war包包含了项目的所有功能。比如上述举例的打车应用，尽管有一个逻辑模块化架构，但应用程序被作为一个单体进行打包和部署。例如，我们所熟知的许多Java应用程序被打包成WAR文件部署在如Tomcat或者Jetty之类的应用服务器上。其他Java应用程序被打包成可执行JAR包。
- 单体应用的特点：
- 容易开发：开发者只需要在专用的开发工具上比如（Eclipse，myEclipse)等就可以管理整个项目代码，完成代码开发工作。
- 容易运行和测试：既然我们能够在本地开发工具上完成整个项目的功能开发和调试，自然也就很容易在我们本地环境上进行测试调试。
- 容易部署：正如我们在举例单体应用构建项目时所说，当应用程序开发，调试，测试完成以后，我们只需要将代码进行打包，然后将打包好的应用程序拷贝到服务器上进行部署即可。
互联网公司架构
再比如，我们拿一个常见的互联网公司的静态逻辑架构来举例，我们通过如下的架构图将系统切分成五层，如下图所示：
- 应用层：面向客户的最终软件产品，直接暴露给互联网的各种App、Web站点以及Wap站点。
- 前置服务层：各种重业务的聚合入口，对具体引用层做大量工作，实现业务调用链条的封装，达成业务逻辑的强实现。
- 业务服务层：包含各种基础的业务服务单元，比如借款系统、还款系统、征信系统、活动系统、爬虫系统、引流系统、文件系统等。
- 基础服务层：不包含状态的基础业务服务，包括但不限于短信网关、文件网关、服务监控等。
- 数据层：包括各种形态的数据存储层，但不限于各种数据库、缓存、消息队列等。
如上我们从传统的构建项目应用和项目架构拆解的角度来给大家解释了什么是单体应用，单体的特点以及传统的应用的架构设计。类似的单体应用在我们以往的互联网发展和企业应用中使用的非常普遍，现在也仍然很多企业都是类似的单体应用。
但是，随着需求的增长，业务的变化，单体应用在慢慢发展和迭代后，也会遇到一些问题，单体应用的瓶颈会逐步显现。