初识微服务
什么是微服务
定义
- 将原本独立的系统拆分成多个小型服务
- 这些小型服务各自独立（各自维护自身的数据存储，业务开发，自动化测试以及独立部署机制独立扩展）
- 服务之间通过基于HTTP的RESTful API进行通信协作
- 更为准确的为每一个服务评估性能容量
- 轻量级的通信协作
- 可以用不同语言来编写
存在的挑战
- 运维人员需要维护的进程数量增加
- 接口要保持一致性，原本单体应用中的代码依赖变成了服务之间的通信依赖
- 分布式的复杂性，需要考虑诸多因素 如网络延时、分布式事务、异步消息...
九大特性
服务组件化
- 一种进程外的组件
- 通过HTTP等通信协议进行协作
按业务组织团队
- 按照业务线的方式进行拆分
- 有效减少服务内部修改所产生的内耗
- 团队边界更为清晰
做“产品”的态度
- 每个小团队都应该以做产品的方式，对产品的整个生命周期负责
智能端点与哑管道
不再如同单体应用的组件直接通过函数调用进行交互协作
由于服务不再一个进程中，组件间的通信模式发生了改变
若仅仅是RPC的方式调用，会导致微服务之间繁琐的通信
更粗粒度的通信协议，微服务架构中，通常以这两种服务调用方式
使用HTTP的
RESTful API或轻量级的消息发送协议，实现信息传递与服务调用的触发通过再轻量级的消息总线上传递消息，类似RabbitMQ等一些提供可靠异步交换的中间件
去中心化治理
去中心化管理数据
- 将原数据库中的存储内容拆分到新的同平台的其他数据库实例中
- 将一些具有特殊结构或者业务特性的数据存储到一些其他技术的数据库实例中(如把日志信息存储到MongoDB中或者用户登录信息存储到Redis中)
基础设施自动化
- 自动化测试
- 自动化部署
容错设计
- 部分服务出现故障，而其他服务仍可正常运行
- 但是设计时必须要考虑自动恢复服务，当故障蔓延的时候必须要快速检查出故障源
- 因此希望再每个服务中实现监控和日志记录的组件，比如服务状态、断路器状态、吞吐量、网络延迟等关键数据的仪表盘等
演进式设计
- 初期使用单体系统的方式来设计与实施
- 随着系统的发展或者业务的需要，将一些经常变动或者是有一定时间效应的内容进行微服务处理
- 逐渐将单体系统中多变的模块逐步拆分出来
- 而稳定不多变的模块就形成一个核心微服务
微服务架构初期
在微服务架构初期，有一些需要解决的问题，下列是各个问题的一些开源解决方案
服务治理
阿里巴巴开源的Dubbo和当当网在其基础上扩展的DubboX，Netfix的Eureka，Apache的Consul...
分布式配置管理
百度的Disconf，Netfix的Archaius，360的QConf，Spring Cloud的Config，淘宝的Diamond...
批量任务
当当网的Elastic-Job，LinkedIn的Azkaban，Spring Cloud的Task...
服务跟踪
京东的Hydra，Spring Cloud的Sleuth，Twitter的Zipkin
为什么选择Spring Cloud
前面列举的框架，只是解决微服务中的某一个问题，而Spring Cloud则是一个解决微服务架构实施的综合性解决框架，在Spring社区的整合下，做了大量的兼容性测试，保证了其拥有更好的稳定性。