- 1.微服务是协同工作的小而自治的服务
- 2.如何建模服务
- 3.应该按照业务建模
- 4.划分上下文容易犯的错误：技术建模
- 5.多个微服务的集成方式
- 6.微服务的部署
- 7.微服务测试
- 8.微服务的监控
- 9.微服务安全问题
- 10.规模化微服务后的故障处理
1.微服务是协同工作的小而自治的服务
微服务的特点：
1) 协同：服务之间通过进程间通信的方式进行调用，服务之间通过网络使用api来通信，从而增强了服务之间的隔离性，避免耦合。一个进程会暴露几个api。
2) 很小，专注于做好一件事。一件事：内聚，业务的边界即服务的边界。很小，如何算小？时间两周内能完成更换，能很好地和团队结构相匹配
3) 自治：可以独立地部署在PaaS平台上，也可以作为一个操作系统的进程存在
什么时候你不应该使用微服务？当你不了解一个领域的时候，找到服务的限界上下文很难。从头开发的时候，先弄稳定再拆分。
2.如何建模服务
什么样的服务是好的服务？松耦合，高内聚
1) 松耦合：修改一个服务不需要修改另外一个服务，保证服务是可以独立修改和部署
如何做到松耦合？限制两个服务之间的不同调用形式的数量，过度的通信可能会导致紧耦合。
2) 高内聚：改变某个行为，最好能够只在一个地方进行修改
松耦合、高内聚的关键是找到服务的边界。找到问题域的边界就可以确保相关的行为能放在同一个地方，并且他们会和其他边界以尽量松耦合的形式进行通信。
服务的边界划分错误后，后续修复的代价会很大。可以考虑先开发为单块架构，等对业务熟悉后，或者系统稳定后，再把单块架构转换成微服务架构。
3.应该按照业务建模
1) 首先考虑业务的功能，这个上下文是做什么的？
建模服务时，应该将这些功能作为关键的操作提供给其它服务
2) 然后考虑共享的数据，“它需要什么样的数据”。
只考虑数据模型的共享，会导致贫血的服务（只基于crud的服务）。
3) 逐步划分：
a. 首先识别出粗粒度的上下文，如仓库，财务
b. 进一步划分嵌套的上下文，如仓库又可分为：订单处理、库存管理、货物接受等。
c. 根据组织架构决定是使用嵌套的方式（如仓库的粗粒度上下文里嵌套订单处理、库存管理及货物接受等细粒度上下文）还是分离的方式（取消仓库上下文，直接将仓库内部的上下文提升到顶层上下文的层次)。订单处理、货物接收及库存管理如果由同一个团队维护，使用嵌套方式,如果由不同的团队维护，使用分离方式。
4.划分上下文容易犯的错误：技术建模
按照技术接缝对服务进行划分（比如按照RPC分成两层：前端和仓储层，而不是按照业务分层），会导致把上下文内部的api暴露出去，导致紧耦合,这就是所谓的洋葱架构（水平分层架构），虽然不一定是错误，但不是首选的方式。
5.多个微服务的集成方式
常用技术：SOAP、XML-RPC、REST、Protocol Buffers等,针对请求/响应的常用技术：rpc、rest。
- 同步：发起一个远程服务调用后，调用方会阻塞自己到整个操作的完成。同步可以使用的协作方式：请求／响应
a. 优势：
i. 可以知道调用成功与否
ii. 技术实现简单
b. 劣势：
i. 运行时间长的应用，需要客户端和服务器之间的长连接
ii. 高延迟
- 异步：调用方不需要等待操作是否完成就可以返回，甚至可能不关心操作完成与否，可以使用的协作方式：请求／响应或者基于事件
a. 优势：
i. 对运行比较长的任务比较有用，否则客户端和服务器之间要开启长连接。
ii. 低延迟
iii. 基于事件的协作方式可以分布处理逻辑，低耦合
b. 劣势：
i. 处理异步通信的技术相对复杂
- 协同（choreography）：告知系统中各个部分各自的职责，具体怎么做的细节留给它们自己，可以用芭蕾舞中的每个舞者来做比喻，通常使用事件驱动的方式，基于事件的异步协作方式常用rabbitmq等消息中间件。
a. 优势：
i. 显著地消除耦合
b. 劣势：
i. 看不到业务流程的进展
ii. 需要额外的工作来监控跨服务的流程，以保证其正确的进行。实际的监控活动是针对每个服务的，但最终把监控的结果映射到业务流程中，在微服务架构里常使用协同方式实现。
6.微服务的部署
持续集成CI能够保证新提交的代码和已有代码进行集成，从而让所有人保持同步。CI服务器会检测到代码已经提交并签出，然后验证代码是否通过编译以及测试能否通过。
持续交付（Continuous Delivery，CD）检查每次提交是否达到了部署到生产环境的要求，并持续反馈这些信息，还会把每次提交当成候选发布版本来对待。CD对多阶段构建流水线的概念进行扩展，从而覆盖软件通过的所有阶段，无论是手动还是自动。
微服务的配置应该单独管理，配置的形式可能是环境的属性文件，或者是传入到安装过程中的一些参数，这样可以避免把生产环境的数据库密码或其他工具密码提交到源代码中。
- 部署微服务的建议
1.引入PaaS（平台即服务）,最大好处是允许你控制运行服务的节点数量，如：Heroku;
2.将主机控制、服务部署等工作自动化，自助式配置单个服务或者一组服务的能力，也可以简化开发人员的工作，理想情况下，开发人员使用的工具链应该和部署生产环境时使用的完全一样，这样方便及早发现问题。
7.微服务测试
微服务架构中测试的复杂度进一步增加，了解测试的类型可用帮助我们尽早交付软件与保持软件高质量之间的平衡。
测试大都是可用自动化测试的，例如性能测试和小范围的单元测试。当然测试也要涵盖服务测试、端到端的测试、部署后的测试、跨功能的测试（非功能性需求）。
8.微服务的监控
微服务的监控的原则：监控小的服务，然后聚合起来看整体
从日志到应用程序指标，集中收集和聚合尽可能多的数据,可用logstash + kibana。
- 关联标识
一个服务调用最终会触发多个下游的服务调用，更为复杂的初始请求有可能生成一个下游的调用链，并且以异步的方式处理触发的事件。一个非常有用的方法是使用关联标识（ID）：在触发第一个调用时，生成一个GUID，然后把它传递给所有的后续调用。类似日志级别和日期，我们也可以把关联标识以结构化的方式写入日志。使用合适的日志聚合工具，就能够对事件在系统中触发的所用调用进行跟踪。
- 标准化
监控这个领域的标准化至关重要：服务之间的多个接口，可以用很多不同的方式合作来提供功能，需要以全局的视角来规划。
1) 标准格式来记录日志
2) 把所有的指标放到一个地方
3) 为度量提供一个标准名称的列表
4) 使用工具在标准化方面提供帮助
- 考虑受众
监控收集的数据会触发一些事件，有些数据会触发支持团队立即采取行动。对于查看这些数据的不同类型的人来说，需要考虑以下因素：
1) 现在需要知道什么
2) 之后想要什么
3) 如何消费数据
9.微服务安全问题
1.通过账户和密码进行身份验证和操作授权
2.深度防御：从网络边界，到子网，到防火墙，到主机，到操作系统，再到底层硬件，都需要在这些方面实现安全措施的能力。
2.服务间的身份验证和授权
3.静态数据的安全：按需对数据、文档进行备份、加密解密
了解系统不同部分的威胁级别，知道什么时候考虑传输中的安全，什么时候需要考虑静态安全，或根本不用考虑安全
10.规模化微服务后的故障处理
当微服务规模化后，故障是无可避免的，以往我们总是想尽力避免故障的发生，而当故障实际发生时，我们往往束手无策。我们花了很多时间在流程设计和应用设计的层面上来阻止故障的发生，但实际上很少花费时间思考如何第一时间从故障中恢复过来。
一.从体验上来解决：功能降级
二.从请求/响应上来解决：加入超时机制、断路器、舱壁
三.从处理结果上解决：如果操作是幂等的，我们可以对其重复多次调用，而不必担任会有不利影响
四.从应用上解决：更强大的主机、一台主机一个微服务、关键业务弹性部署、多云服务数据商备份、异地灾备、负载均衡、重构系统、作业队列、重新设计
五.从数据库上解决：扩展数据库，主从复制、读写分离
六.从缓存上解决：客户端、代理服务器和服务器端缓存，但注意设置合适的缓存失效时间