微服务设计-学习笔记1

微服务

微服务定义

微服务就是一些协同工作的 小而 自治的服务

主要好处

• 技术异构性
• 弹性
• 扩展
• 简化部署
• 与组织结构相匹配
• 可组合性
  易于重用已有功能
• 对可替代性的优化
  使用微服务架构的团队可以在需要时轻易地重写服务，或者删除不再使用的服务

面向服务的架构

SOA(Service-Oriented Architecture，面向服务的架构)是一种设计方法，其中包含多个服务，而服务之间通过配合最终会提供一系列功能。一个服务通常以独立的形式存在于操作系统进程中。服务之间通过网络调用，而非采用进程内调用的方式通信
<u>微服务架构是SOA的一种特定方法</u>

演化式架构师

架构师的演化视角

架构师必须改变那种从一开始就要设计出完美产品的想法，相反我们应该设计出一个合理的框架，在这个框架下可以慢慢演化出正确的系统。

• <u>架构师更像是城市规划师</u>

架构师的职责之一就是保证该系统适合开发人员在其上工作，架构师应该专注于大方向上，只在很有限的情况下参与到非常具体的细节实现中来

分区

• 分区
  它们应该是我们的服务边界，或者是一些粗粒度的服务群组。

我们应该考虑不同的服务之间如何交互，或者说保证我们能够对整个系统的健康状态进行监控

要求标准

• 监控
  能够清晰地描绘出跨服务系统的健康状态非常关键。建议确保所有的服务使用同样的方式报告健康状态及其监控相关数据。
  日志功能和监控情况类似：<u>也需要集中式管理</u>
• 接口
  选用少数几种明确的接口技术有助于新消费者的集成
• 架构安全性
  必须保证每个服务都可以应对下游服务的错误请求

代码治理

• 范例
  如果在系统中人们有比较好的代码范例可以模仿，那么开发人员也就不会错的很离谱
• 裁剪服务代码模版
  使用服务代码模版，一定要确保它能够简化开发人员的工作，而不是使其复杂化

如何建模服务

什么样的服务是好服务

• 松耦合
• 高内聚
  找到问题域的边界可以确保相关的行为能放在同一个地方，并且它们会和其他边界以尽量松耦合的形式进行通信

界限上下文

• 定义

  一个由显式边界限定的特定职责

• 模块和服务
  共享特定的模型
  一旦发现了领域内部的界限上下文，一定要使用模块对其进行建模，同时使用共享和隐藏模型

过早划分

过早将一个系统划分成微服务的代价非常高，尤其是在面对新领域时。很多时候，将一个已有的代码库划分成微服务，要比从头开始构建微服务简单得多

业务功能

建模服务时，应该将功能作为关键操作提供给其协作者(其他服务)

逐步划分上下文

当考虑微服务的边界时，首先考虑比较大的、粗粒度的那些上下文，然后当发现合适的缝隙后，再进一步划分出那些嵌套的上下文

关于业务概念的沟通

通信形式在整个组织范围内都非常重要