By Braveyly 2018-06-14 sz
九、微服务
9.1 定义
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间采
用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API），每个服务围绕着具体业
务进行构建，并且能够被独立地部署到生产环境中。
9.2 原理
9.2.1 概述
微服务架构的团队组织方式不同于传统的团队组织方式，它提倡以业务为核心，按业务
能力来组织团队，团队中的成员具有多样性的技能。也就是一个团队中的人员具备独立完成
微服务的能力，矩阵责任田的方式组建的开发团队，缺乏主人翁精神，难以制定有效的奖惩
机制，缺乏产品成就感。
微服务架构将一个应用拆分成多个独立的，具有业务属性的服务，每个服务运行在不同
的进程中，服务之间通过轻量级通信机制互相协同，从而为终端用户提供业务价值。
微服务架构强调的是一种独立开发、独立测试、独立部署、独立运行的高度自治的架构模式，
也是一种更灵活、更开放、更松散的演进式架构。
9.2.2 RESTful 和 RPC
所谓轻量级通信机制，通常指语言无关、平台无关的交互方式。轻量级通信的格式，一
般有 XML 或 JSON。轻量级通信的协议，一般是基于 HTTP，能让服务间的通信变得标准化并
且无状态化。其中，REST 是实现服务之间相互协作的轻量级通信机制之一。
而对比于传统的 RPC 方法，与平台和语言耦合度都比较高，灵活性和扩展性比较差。
远程过程调用的弊端：
（1）耦合度高。一旦使用后，通信的双方就很难切换到其他的语言或者平台上。
（2）灵活性差。传输的格式是二进制，客户端和服务端要提供序列化和反序列化操作，
意味着，通信两端的任一方发生变化时，会对另外一端造成影响。
9.2.3 单体应用和微服务
单体应用优点：
（1）方便调试，代码都在一起；
（2）没有分布式开销，所有服务都在本地容器内；
（3）中小型项目可以快速迭代，不需要太多资源
单体应用容易造成的问题：
（1）版本管理难：当项目规模变大时，代码容易产生冲突。
（2）稳定性差：局部服务有问题，可能会影响整体；
（3）可维护性差：规模扩大复杂性直线上升，造成系统不易理解；
braveyly
- 粉丝: 92
- 资源: 49
我的内容管理
收起
- 我的资源
快来上传第一个资源
我的收益 登录查看自己的收益
我的积分
登录查看自己的积分
我的C币
登录后查看C币余额
我的收藏 
我的下载 
下载帮助
评论0