架构杂谈《二》
服务化到微服务
1、微服务的产生
随着互联网企业的不断发展，海量用户发起的大规模、高并发请求是企业不得不面对的，上一篇 架构杂谈《一》杂谈的SOA服务化系统能够分解任务，让每个服务更简单、职责单一、更易于扩展。但无论是Web Service 还是ESB，都有时代遗留下的问题。
Web Service：
1）依赖中心化的服务发现机制
2）使用SOAP通讯协议，通常使用XML格式来序列化通信数据，XML格式的数据冗余太大，协议太重
3）服务化管理和治理设施并不完善
ESB：
1）ESB 虽然是SOA实现的一种方式，却更多地体现了系统集成的便利性，通过统一的服务总线将各个服务组合在一起
2）组合在ESB上的服务本身有可能是一个臃肿的服务
3）系统内部的复杂性仍然存在。ESB试图通过总线来掩盖系统内部的复杂性
4）对于总线本身中心化的管道模型，系统变更时影响的范围会随之扩大
出现问题解决问题是人类进步的阶梯，对于软件架构也是一样，近年来服务架构设计得到了进一步的演化和发展，微服务架构已经出现在不同公司的讨论、设计和实践中，经过市场检验的东西肯定会被大家所接受。
微服务架构提倡将软件应用设计成多个可独立开发、配置、运行和维护的子服务，子服务之间通过良好的接口定义通信机制，通常使用RESTful风格的API形式来通信。因为RESTful 风格的 API 通常是在 HTTP 或者 HTTPS 通道上传输 JSON 格式的数据来实现的， HTTP协议有跨语言、跨异构系统的优点， 当然也可通过底层的二进制协议、消息队列协议等进行交互。这些服务不需要中心化的统一管理，每个服务的功能可自治，并且可由不同的语言、系统和平台实现 。
微服务架构致力于松耦合和高内聚的效果，与SOA和ESB相比，不再强调服务总线和通信机制的多样性，通常通过RESTful 风格的API和轻量级的消息通信协议来完成。
微服务架构并不是为了拆分而拆分，真正的目的是通过对微服务进行水平扩展解决传统的单体应用在业务急剧增长时遇到的问题，而且由于拆分的微服务系统中专业的人做 专业的事，人员和项目的职责单一、低藕合、高内聚，所以产生问题的概率就会降到最小。
2、微服务与单体的对比
（微服务架构图）
从上图可以得到：
1） 微服务把每一个职责单一的功能放在一个独立的服务中
2） 每个服务运行在一个单独的进程中
3） 每个服务有多个实例在运行，每个实例可以运行在容器化平台内
4） 每个服务有自己的数据存储，实际上，每个服务应该有自己独享的数据库、缓存、消息队列等
5） 每个服务都可根据性能需求独立地水平伸缩
（单体架构图）
通过对比，可以得到传统单体架构的特点：
1） 传统单体架构将所有模块化组件糅合后运行在同一个服务的进程中
2） 某个模块发生变更时，需要将所有的模块编译、打包上线
3） 久而久之，模块间的依赖将会不清晰，互相耦合，互相依赖成为常态
通过将两种架构对比来看，微服务架构更加的灵活并且可水平伸缩，可以让专业的人干专业的事。
3、微服务与SOA服务的对比
微服务架构的一些特点与 SOA 服务化架构相似， 事实上微服务架构与 SOA 服务化架构并不冲突，它们一脉相承，微服务架构是服务化架构响应特定历史时期的使用场景的延续，是服务化进行升华井落地的一种实现方式。 SOA 服务化的理念在微服务架构中仍然有效，微服务在 SOA 服务化的基础上进行了演进和叠加，形成了适合现代化应用场景的一个方法论。
经过几十年互联网的高速发展，以及敏捷、持续集成、持续交付、DevOps、云技术等的深入人心，服务架构的开发、测试、部署以及监控等，相比SOA已经发生大的变化。