摘要：
http://www.cnblogs.com/mengdd/p/3447464.html 阅读全文
摘要：
《SpringBoot揭秘》 《微服务设计》 《REST实战》 《SOA与REST--用REST构建企业级SOA解决方案》 阅读全文
摘要：
服务独立部署： 基于通用的通信机制，首选基于HTTP的Restful API 服务器端可自由添加非必须的请求参数 服务器端可自由添加响应参数 服务器端可自由添加错误代码 服务器端通过服务版本号控制不兼容的修改 阅读全文
摘要：
协议： 普通场合优先选择基于HTTP的Restful API(基于HTTP协议，互操作性好，各种编程语言都支持；可伸缩性好；松耦合；易于测试) API实现技术应该避免与客户端耦合 特殊场合可以选择二进制的RPC协议(对低延迟、实时性要求极高；松耦合不重要；二进制的RPC协议：基于Google Pro 阅读全文
摘要：
判断良好服务的标准 服务自身保持高内聚(有自己独立的领域模型) 封装内部变化，通过API对外暴露功能(只有本服务自身的代码可访问本领域模型的数据库，其他系统只能通过本服务暴露的API间接访问本服务的数据) 与其他服务保持松耦合，能够独立修改和部署(依赖本服务的其他系统不必同时修改和部署) 能够实现服 阅读全文
摘要：
问题： 划分服务的原则是什么 服务之间选择何种轻量级的通信协议 如何做到服务的独立部署 如何确定使用何种编程语言?控制多语言带来的复杂度 如何做到服务的去中心化 如何解决大量微服务引入的运维成本 阅读全文
摘要：
基础知识: 部署微服务而设计的开发框架 微服务运维工具 基于Docker的部署和管理 阅读全文
摘要：
好处： 解决传统单块风格应用的问题： 单一代码库，代码维护复杂 单一发布单元，测试困难 单一发布单元，发布困难 对服务器硬件配置要求极高，垂直扩展困难 无法做到无状态，水平扩展困难 解决集中式服务管理机制的问题： 有可能出现单点故障 可伸缩性差，容易出现性能瓶颈 解决重量级通信机制的问题： 基于HT 阅读全文
摘要：
不足： SOA没有为服务如何划分提出具体指导 SOA无法防止服务之间过度耦合 SOA通常使用重量级的通信协议，例如：SOAP/WSDL SOA中常常有集中式的服务管理机制，例如:UDDI、ESB SOA未强调服务的独立部署 SOA难以使用不同的编程语言使用 SOA的性能和可伸缩性无法满足面向互联网大 阅读全文
摘要：
全称：微服务架构(Microservice Architecture) Martin Fowler的定义： 微服务架构是一种架构模式，它提倡将单一应用程序划分为一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务之间采用轻量级的通信机制(通常是基于HTTP 阅读全文