微服务设计

1.微服务

1.1 什么是微服务

1.1.1 很小，专注于做好一件事  

        单一职责原则的理念。

1.1.2 自治性

        一个微服务就是一个独立的实体，它可以独立地部署在PAAS上，也可以作为一个操作系统进程存在。服务暴露出API，服务间通过API通信。

1.2 主要好处

1.2.1 技术异构性 

        可以用不同的技术栈来实现不同服务。

1.2.2 弹性

        降低整个服务不可用的问题。

1.2.3 扩展

        当存在性能问题时，可以只对需要扩展的服务进行扩展，把部分不需要扩展的服务运行在更小的、性能稍差的硬件上。

1.2.4 简化部署

        更改程序时，只需重新部署一个小服务，便于回滚和不影响整体功能。

1.2.5 与组织结构相匹配

        小团队模式更高效。

1.2.6 可组合型

        在微服务架构中，系统会开放很多接口供外部使用。当情况发生改变时，可以使用不同的方式构建应用，而整体化应用程序只能提供一个非常粗粒度的接口供外部使用。

1.2.7 对可替代性的优化

        重构、删除服务时方便。

1.3 面向服务的架构

        SOA（面向服务的结构）是一种设计方法，其中包含多个服务，而服务之间通过配合最终会提供一系列功能。一个服务通常以独立的形式存在于操作系统进程中。服务之间通过网络调用，而非进程内调用的方式进行通信。

2.如何建模服务

2.1 什么样的服务是好服务

2.1 松耦合

        能够独立修改及部署单个服务而不需要修改系统的其他部分。

2.2 高内聚

        把相关的行为放在一个服务里

2.2 逐步划分

        先考虑比较大的、粗粒度的，然后当发现合适的缝隙后，再进一步划分。

3.集成   

3.1 寻找理想的集成技术

• 避免破坏性修改
• 保证API的技术无关性
• 使你的服务易于消费方使用
• 隐藏内部实现细节

3.2 为用户创建接口

3.3 共享数据库

        使用数据库集成会使高内聚和低耦合失效，外部系统能查看内部实现细节并绑定。

3.4 同步与异步

        同步——请求/响应

        异步——基于事件

3.5 编排与协同

        编排——依赖于某个中心大脑，“上帝”，很容易知道异常

        协同——异步订阅，消除耦合，但需要监控系统

        请求/响应方式可以考虑RPC（Remote Procedure Call，远程过程调用）、REST（REpresentational State Transfer，表述性状态转移）。

3.6 RPC       

• 技术的耦合
• 隐藏远程调用的复杂性，会花大量时间对负荷进行封装和解封装
• 网络不可靠
• 脆弱性，一处更改服务器和客户端都要改

3.7 REST

        资源、消费者

3.8 版本管理

        版本共存，v1、v2，允许平滑过渡。

4.分解单块系统

4.1 数据库

4.1.1 打破外键关系

        调用API来访问数据，而不是直接访问数据库。

4.1.2 共享静态数据

        放入配置文件或代码，比如国家代码。

4.1.3 共享数据

        通过API来查数据

4.1.4 共享表

        拆分表

5.规模化微服务

5.1 故障无处不在

        网络、硬件不可靠

5.2 功能降级

        某个服务不可用时，不要影响整个系统。