微服务-学习笔记

基本思想

围绕业务领域组件来创建应用，让应用可以独立的开发、管理和加速。

优点

每个微服务组件都是简单灵活的，能够独立部署。不再像以前一样，应用需要一个庞大的应用服务器来支撑。可以由一个小团队负责更专注专业，相应的也就更高效可靠。微服务之间是松耦合的，微服务内部是高内聚的，每个微服务很容易按需扩展。微服务架构与语言工具无关，自由选择合适的语言和工具，高效的完成业务目标即可。

缺点

依赖服务变更很难跟踪，其他团队的服务接口文档过期怎么办？依赖的服务没有准备好，如何验证我开发的功能。部分模块重复构建，跨团队、跨系统、跨语言会有很多的重复建设。微服务放大了分布式架构的系列问题，如分布式事务怎么处理？依赖服务不稳定怎么办？运维复杂度陡增，如：部署物数量多、监控进程多导致整体运维复杂度提升。

四个原则

AKF拆分原则前后端分离无状态服务Restful通信风格

AKF拆分原则，按照x,y,z三个维度，可以将一个单体系统，进行无限扩展。

X 轴 ：指的是水平复制，组成多实例的单体系统集群。Z 轴 ：是基于类似的数据分区，比如按照用户请求的地区进行数据分区。Y 轴 ：基于不同的业务拆分。

无状态服务
把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。

例如我们以前在本地内存中建立的数据缓存、Session缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。

微服务架构的基础框架选择
Spring Cloud，是Spring Source的产物
Dubbo，是阿里巴巴服务化治理的核心框架，开发者指南

学习资料如下：
1. 微服务的4个设计原则和19个解决方案
2. The Art of Scalability
3. howtocookmicroservices
4. http://www.cnblogs.com/Andon_liu/p/6801534.html
5. 持续部署微服务的实践和准则
6. 微服务架构的基础框架选择：Spring Cloud还是Dubbo？
7. 微服务的团队应对之道
8. 通过做一个基于Node的微服务器来学习Docker
9. WeText项目：一个基于.NET实现的DDD、CQRS与微服务架构的演示案例