主页

索引

模块索引

搜索页面

微服务架构

优势:

1. 服务简单，只关注一个业务功能
2. 每个微服务可由不同团队开发
3. 微服务是松散耦合的
4. 可用不同的编程语言与工具开发

挑战:

1. 运维开销
2. DevOps要求
3. 隐式接口
4. 重复劳动
5. 分布式系统的复杂性
6. 事务、异步、测试面临挑战

与单体式架构相比，微服务架构有很多优点，例如:

易于开发与维护：微服务相对小，易于理解
独立部署：一个微服务的修改不需要协调其它服务
伸缩性强：每个服务都可按硬件资源的需求进行独立扩容
与组织结构相匹配：微服务架构可以更好将架构和组织相匹配，每个团队独立负责某些服务，获得更高的生产力
技术异构性：使用最适合该服务的技术，降低尝试新技术的成本
企业环境下的特殊要求：去中心化和集中管控/治理的平衡，分布式数据库和企业闭环数据模型的平衡

优点:

提升开发速度，每个服务足够内聚，足够小，代码容易理解；
服务独立测试、部署、升级、发布；
按需定制的 DFX，提高资源利用率
    每个服务可以各自进行 x 扩展和 z 扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上
    每个服务按需要选择 HA 的模式，选择接受服务的实例个数；
容易扩大开发团队
    可以针对每个服务（service）组件开发团队
提高容错性（fault isolation）
    一个服务的内存泄露并不会让整个系统瘫痪
    新技术的应用，系统不会被长期限制在某个技术栈上

缺点:

没有银弹，微服务提高了系统的复杂度
开发人员要处理分布式系统的复杂性
服务之间的分布式通信问题
服务的注册与发现问题
服务之间的分布式事务问题
数据隔离再来的报表处理问题
服务之间的分布式一致性问题
服务管理的复杂性，服务的编排
不同服务实例的管理

微服务架构的优势:

1. 服务的独立部署
  每个服务都是一个独立的项目，可以独立部署，不依赖于其他服务，耦合性低。

2. 服务的快速启动
  拆分之后服务启动的速度必然要比拆分之前快很多，因为依赖的库少了，代码量也少了。

3. 更加适合敏捷开发
  敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行。
  服务拆分可以快速发布新版本，修改哪个服务只需要发布对应的服务即可，不用整体重新发布。

4. 职责专一，由专门的团队负责专门的服务
  业务发展迅速时，研发人员也会越来越多，每个团队可以负责对应的业务线，服务的拆分有利于团队之间的分工。

5. 服务可以按需动态扩容
  当某个服务的访问量较大时，我们只需要将这个服务扩容即可。

6. 代码的复用
  每个服务都提供 REST API，所有的基础服务都必须抽出来，很多的底层实现都可以以接口方式提供。

微服务架构的劣势:

1）分布式部署，调用的复杂性高
  单体应用的时候，所有模块之前的调用都是在本地进行的，
  在微服务中，每个模块都是独立部署的，通过 HTTP 来进行通信，
  这当中会产生很多问题，比如网络问题、容错问题、调用关系等。

2）独立的数据库，分布式事务的挑战
  每个微服务都有自己的数据库，这就是所谓的去中心化的数据管理。
  这种模式的优点在于不同的服务，可以选择适合自身业务的数据，比如:
    订单服务可以用 MySQL、评论服务可以用 MongoDB、商品搜索服务可以用 ElasticSearch。

  缺点就是事务的问题了，目前最理想的解决方案就是柔性事务中的最终一致性。

3）测试的难度提升
  服务和服务之间通过接口来交互，当接口有改变的时候，对所有的调用方都是有影响的，
  这时自动化测试就显得非常重要了，如果要靠人工一个个接口去测试，那工作量就太大了。
  这里要强调一点，就是 API 文档的管理尤为重要。

4）运维难度的提升
  在采用传统的单体应用时，我们可能只需要关注一个 Tomcat 的集群、一个 MySQL 的集群就可以了，
  但这在微服务架构下是行不通的:
  当业务增加时，服务也将越来越多，服务的部署、监控将变得非常复杂，这个时候对于运维的要求就高了

挑战:

微服务故障的概率和微服务或微服务节点的数量是成正比

优势:

1. 小而灵活
    使服务直接职责和边界更清晰，更加易于维护
    对可替代性的优化
2. 技术异构性
3. 故障隔离
4. 按需伸缩
    “节省成本就是创造价值”。
5. 简化部署
6. 与组织架构相匹配
    避免出现过大的代码库，从而获得理想的团队大小和生产力
    可以避免异地团队的出现，降低团队之间的沟通成本
7. 灵活的组合
8. 安全

特点:

1. 单一职责:
  独立的业务单独放在一个项目中，比如订单服务作为一个项目
  每个微服务都需要满足单一职责原则，微服务本身是内聚的，因此微服务通常比较小。
    如：每个微服务按业务逻辑划分，每个微服务仅负责自己归属于自己业务领域的功能。
2. 自制
  一个微服务就是一个独立的实体，
  它可以独立部署、升级，服务与服务之间通过 REST 等形式的标准接口进行通信，
  并且一个微服务实例可以被替换成另一种实现，而对其它的微服务不产生影响
3. 轻量级的通信: http, rpc(非轻量级的如java的RMI)
4. 隔离性: 每个服务间相互隔离、不干扰
5. 有自己的数据
6. 技术多样性

微服务架构诞生背景:

互联网行业的快速发展，需求变化快，用户数量变化快
敏捷开发深入人心，用最小的代价，做最快的迭代，频繁修改、测试、上线
容器技术的成熟，是微服务的技术基础

微服务只是结果，而不是最终目的。微服务的目的是有效的拆分应用，实现敏捷开发和部署

Docker最大的特点就是轻量，启动速度快，扩张快，部署快，因此具体实现业务的服务，都应该放在Docker里面进行部署，但是一定要强调，并且一定要保证无状态化，这是快速扩张，自主更新的基础

  • 无状态化包括:

    1. 没有Session
2. 磁盘中没有任何中间结果文件
3. 内存中没有任何处理中间结果，状态

比较现实的替代方案是Redis，NFS文件共享等等

迁移微服务架构

如何从单体架构=>微服务架构:

- 单体架构
- 垂直架构
- SOA架构
- 微服务架构

Jaime Buelta谈微服务及其好处

简介:

《Hands-On Docker for Microservices with Python》 一书的作者
在开始使用微服务之前，Buelta 建议在通用软件架构和 Web 服务方面打下坚实的基础。
  “在处理微服务及其后续工作时，它们将会非常有用，” 他说。

微服务：好处和风险:

传统的单体应用程序将所有的功能都封装在一个单元中。
相反，在微服务架构中，应用程序被划分为可以单独部署、升级和替换的小型独立服务。
每个微服务都是针对单个业务目的而构建的，它使用轻量级机制与其他微服务通信。

Buelta 解释说，“
  微服务架构是一种构建系统的方式，
  其中，几个独立的服务按定义好的方式彼此通信（通常通过 Web RESTful 服务）。
  关键在于每个微服务都可以独立更新和部署。
”

微服务架构不仅规定了如何构建应用程序，还规定了如何组织团队。
  他补充道，“虽然通常我们使用所涉及的技术来描述（它），但它也是一种组织结构。
  每个独立的团队都可以完全拥有一个微服务。这使得组织的发展可以不受开发人员冲突的影响”。

微服务的主要好处之一是它可以赋能创新，而不会对整个系统造成太大影响。
使用微服务，你可以进行水平扩展、有确定的模块边界、使用多种技术进行并行开发。

谈到与微服务相关的风险时，Buelta 说，“
  采用微服务的主要风险，尤其是当起步于一个单体应用时，是设计的服务不是真正独立的。
  这将增加服务间通信的开销和复杂性。”

他补充道，“从长远来看，微服务系统的设计需要一个高层次的视角。我对正在朝着这种架构发展的组织的建议是，让某人负责 “大局”。你不想只见树木不见森林。”

适用「微服务」前提:

“随着业务和团队的增长，他们需要更好的协调。开发人员开始经常互相干扰。了解特定代码段的意图比较困难。这时候进行迁移，将功能分隔，获得更好的清晰度，是有意义的。每个团队都可以设定自己的目标，并且基本上可以独立工作，暴露出一个清晰的外部接口。但要想让这一切有意义，就必须有足够数量的开发人员，” 他补充道。

微服务迁移的最佳实践:

“微服务架构成功的关键是每个服务尽可能独立。”
“这里出现的问题是‘如何使服务独立？’发现系统之间的相互依赖关系的最佳方法是从新特性的角度进行思考：如果有一个新特性，是否可以通过修改单个服务来实现？什么样的特性需要协调几个微服务？是常见的需求，还是罕见的需求？没有哪种设计是完美的，但至少有助于做出明智的决定。”
Buelta 建议使用正确的方法做而不是做两次。
他补充道，“一旦迁移完成，就很难对微服务的边界进行更改。在项目初期投入的时间是值得的。”

从一个架构模式迁移到另一个架构模式是一个很大的变化。我们问他和他的团队在这个过程中遇到了什么挑战，他说，“最困难的挑战其实是人。它们往往被低估，但转向微服务实际上改变了人们的工作方式。这可不是件容易的事！”

他补充道，“我遇到过这样一些问题，比如必须为开发人员提供足够的培训和支持。特别是，解释一些改变背后的根本原因。这有助于开发人员理解，为什么他们要做出这些让人感到如此沮丧的改变。”

例如，从单体应用迁移的一个常见抱怨是部署时需要协调，而以前是一次单体发布。这需要更多地考虑如何确保向后兼容和最小化风险。这有时不是很明显，需要专门说明。”

参考

主页

索引

模块索引

搜索页面