面向服务架构思想相同，微服务架构是SOA架构的发展，是面向服务的架构设计， 强调服务的松耦合、高内聚和明确的边界划分。
服务粒度
架构风格
SOA架构重通道轻终端，一把采 用集中式的企业服务总线ESB。
云技术应用 数据库模式 业务敏捷性
一般面向传统技术架构。 多采用集中式数据库。 通过提高服务复用，提升业务敏 捷性。 支持RPC、RestFul，偏向于使用 SOAP等RPC模式，支持同步调用 异步调用模式，强调异步调用。 大
据平台的支撑。
• • 管理运行维护、监控、自动化部署的要求很高，需要云技术的支撑。 微服务必然面临分布式事务CAP（一致性、可用性、分区容忍性）的问题，
Hale Waihona Puke AP(牺牲一致性，达到最终一致性）or CP（牺牲可用性）。
• 微服务的架构需要采用循序渐进，快速迭代的方式推进。对于无法很好把控 的业务功能或系统可以先集中再逐步微服务化。
•微服务架构模式-组件、模块
每一微服务一般完成某个特定的功能，比如下单管理、客户管 理等等。每一个微服务都是微型六角形应用，都有自己的业务 逻辑、适配器和数据库。优势解决了系统逻辑过于复杂，便于 快速开发，支持服务快速开发独立部署和横向扩展。
•API GateWay：
一些REST API也会向终端和移动互联用户采用的移动应用开放， 应用并不直接访问后台服务，而是通过API Gateway来传递中 间消息。
微服务轻通道重终端，一般采用去中心分布 式系统，但需要具备基本的服务注册，服务 代理，服务发布，服务简单的路由，安全访 问和授权，服务调用消息和日志记录这些功 能还是需要具备如ESC、dubbo等。 微服务对外需要暴露集中式API GateWay。 源自互联网，采用云技术，如docker。 注重每一个组件有独立数据库。这很难做到！ 更重视敏捷性，重视轻快，持续迭代。强调 持续开发集成的开发模式，强调自动化运维 和简易横向扩容。 支持RPC、RestFul，偏向于采用HTTP API的 Rest调用方式，通过Uri表明资源和操作。 注重流程编排和事件触发协作。 很大
•
微服务架构提供一个原则性的方法，原则需要遵守但不可盲目追求原则而完
全不考虑实际情况。“规则对于智者来说是指导，对于愚蠢者来说是遵从”
目录
1
微服务架构介绍
2
微服务相关技术
3
Docker技术介绍
集成技术选型（1/2）
• 保证API的技术无关性，无论采用RPC还是RestFul方式
– 例如使用Java RMI，客户端和服务端必须使用Java语言就存在技术相关 性，而采用HTTP+XML或是HTTP+Json则不存在技术相关性。 如采用SOAP，返回增加一个字段时，客户端可能需要重新编译修改， ，而采用普通XML报文，多返回一个字段并不会影响使用。 凡是简单，易于使用，快速便捷内容会被留下。便捷简单和耦合度存 在关联，需要取舍。如开发统一的API SDK包，SDK应只包含通信安全等 代码，不应包含业务逻辑。 例如对数据局库的访问是采用JDBC还是其他，是采用Java语音还是C语 音，是采用NIO还是BIO。 数据库共享容易导致服务高内聚原则遭受破坏。 当次服务调用包含了所需的所有信息
微服务IT架构
中 国 领 先 的 整 合 IT 服 务 商
目录
1
微服务架构介绍
2
微服务集成技术
3
Docker技术介绍
微服务的概念 •单体式架构模式-系统
模块化设计，但各模块打包在一起部署。部署简单，但应用逻 辑复杂，依赖程度高，开发效率不高，不易扩展，模块间容易 互相影响，架构和开发语音调整困难。
微服务的优势
• 技术多样性选择-合适的工具和技术干合适的事情 • 具备弹性动态伸缩能力-随需扩展，故障能舱壁 • 实现简化部署，一键部署一键安装一键回退
与业务、 组织匹配
技术异构性， 多语言，多 选择
弹性动态 伸缩
• 微服务具有可组合简易快速拼装
• 小，简单，容易被替换性，技术无关性 • 微服务是对系统深入了解的情况实现的模块分解 可替代性
服务调用方式
系统访问量
微服务的原则
围绕业务概 念建模
高度可观察
坚持自动化
微服务 自动隔离失 败舱壁 自治的小 服务 高内聚松耦 合屏蔽内部 实现细节
组件独立部 署
去中心化
微服务是一把双刃剑 思考？
•
•
业务领域掌握的程度决定架构的合理性，错误不可避免。
业务模块的分解，模块应该具备独立的数据库，所以数据库的分解和数据的 共享整合非常困难，还不足以通用的业务建立准则。数据整合共享需要大数
编排（组合调用）：信用卡还款
编排 or 协同
– 协同（发布订阅）：转账完毕，需要通知短信系统、反洗钱系统、总账系统、 积分系统、大数据平台、监控系统……
RPC：SOAP（HTTP），RMI，JMX，JMS，TCP REST：HTTP，URI，CRUD（POST，GET，PUT和DELETE） xml Json 混合模式 应该存在微服务多版本吗？ 多版本并存，灰度发布的概念
微小 专注
自动化部 署 可组合型
与业务支持
• 支持敏捷开发模式，注重开发测试运营的一体化， 实现DevOps
开发人员
DevOps
技术运营 质量人员
微服务架构和SOA架构的差别
比较内容
服务理念
SOA架构
SOA架构的服务强调系统间的交 互需要服务化，服务的粒度相对 较粗。
微服务架构
微服务架构强调业务系统需要彻底的组件化 和服务化，单个业务系统会拆分为多个可以 独立开发，设计，运行和运维的小应用。服 务粒度注重小而美。 暴露组件外功能为微服务。
•
避免破坏性修改，不可避免情况下需要及早发现破坏性的修改
–
•
使服务易于服务消费者使用和调度
–
•
实现服务的高内聚松耦合，对外屏蔽实现细节
–
•
•
尽量避免共享数据库，虽然有时候很难做到
– –
坚持服务的无状态调用（有些也称为服务即状态）
集成技术选型（2/2）
• • 同步 or 异步
–
–
同步采用请求响应模式，异步基于事件通知和回调机制。
•
RPC or Rest
– –
•
XML or JSON or其他
– – –
•
服务多版本
– –
REST
• • • REST：Representational State Transfer，表征性状态转移，支持交易无 状态 REST默认使用HTTP协议 RESTFUL