一、什么是微服务
微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成任务。在所有情况下，每个任务代表着一个小的业务能力。
二、单体架构(Monolithic Architecture )
企业级的应用一般都会面临各种各样的业务需求，而常见的方式是把大量功能堆积到同一个单体架构中去。比如：常见的ERP、CRM等系统都以单体架构的方式运行，同时由于提供了大量的业务功能，随着功能的升级，整个研发、发布、定位问题，扩展，升级这样一个“怪物”系统会变得越来越困难。
这种架构模式就是把应用整体打包部署，具体的样式依赖本身应用采用的语言，如果采用java语言，自然你会打包成war包，部署在Tomcat或者Jetty这样的应用服务器上，如果你使用spring boot还可以打包成jar包部署。其他还有Rails和Node.js应用以目录层次的形式打包。
大部分企业通过SOA来解决上述问题，SOA的思路是把应用中相近的功能聚合到一起，以服务的形式提供出去。因此基于SOA架构的应用可以理解为一批服务的组合。SOA带来的问题是，引入了大量的服务、消息格式定义和规范。
多数情况下，SOA的服务直接相互独立，但是部署在同一个运行环境中（类似于一个Tomcat实例下，运行了很多web应用）。和单体架构类似，随着业务功能的增多SOA的服务会变得越来越复杂，本质上看没有因为使用SOA而变的更好。图1，是一个包含多种服务的在线零售网站，所有的服务部署在一个运行环境中，是一个典型的单体架构。
单体架构的应用一般有以下特点：
- 设计、开发、部署为一个单独的单元。
- 会变得越来越复杂，最后导致维护、升级、新增功能变得异常困难。
- 很难以敏捷研发进行开发和发布。
- 部分更新都需要重新部署整个应用。
- 水平扩展：必须以应用为单位进行扩展，在资源需求有冲突时扩展变得比较困难（部分服务需要更多的计算资源，部分需要更多内存资源）
- 可用性：一个服务的不稳定会导致整个应用出问题。
- 创新困难：很难引入新的技术和框架，所有的功能都构建在同质的框架之上。
- 运维困难：变更或升级的影响分析困难，任何一个小修改都可能导致单体应用整体运行出现故障。
三、微服务架构
微服务，可以拆分为"微"和“服务”二字，“微”即小的意思，那么到底多小才算“微”呢？可能不同的团队有不同的答案。从参与微服务的人数来讲，单个服务从架构设计、代码开发、测试、运维的人数加起来是8~10人才算微。那么何为“服务”呢？按照微服务概念的提出者Martin Fowler给出的定义：“服务”是一个独立运行的单元组件，每一个单元组件运行组在独立的进程宗，组件与组件之间通常使用HTTP这种轻量级的通信机制进行通信。
微服务有以下几个特点：
- 按照业务来划分服务，单个服务的代码量小，业务单一，易于维护。
- 每个微服务都有独立的基础组件，例如数据库、缓存等，且运行在独立的进程中。
- 微服务之间的通信是通过HTTP协议或者消息组件，且具有容错能力。
- 微服务有一套服务治理的解决方案，服务之间不耦合，可以随时加入和剔除服务。
- 单个服务能够集群化部署，并且有负载均衡能力。
- 整个微服务系统应该有一个完整的安全机制，包括用于验证、权限验证、资源保护等。
- 整个服务系统有链路追踪的能力。
- 有一套完成的实时日志系统。
微服务具有以上这些特点，那么微服务需要具备一些什么样的功能呢？微服务的功能主要体现在以下几个方面。
- 服务的注册和发现。
- 服务的负载均衡。
- 服务的容错。
- 服务网关。
- 服务配置的统一管理。
- 链路跟踪。
- 实时日志。
四、微服务设计
那我们在微服务中应该怎样设计呢。以下是微服务的设计指南：
- 职责单一原则（Single Responsibility Principle）：把某一个微服务的功能聚焦在特定业务或者有限的范围内会有助于敏捷开发和服务的发布。
- 设计阶段就需要把业务范围进行界定。
- 需要关心微服务的业务范围，而不是服务的数量和规模尽量小。数量和规模需要依照业务功能而定。
- 于SOA不同，某个微服务的功能、操作和消息协议尽量简单。
- 项目初期把服务的范围制定相对宽泛，随着深入，进一步重构服务，细分微服务是个很好的做法。
后期我会在博客中具体介绍SpirngCloud的各个组件，大家一起进步加油~