名词解释-微服务

发表于 分类于 阅读次数： 本文字数： 3.9k 阅读时长 ≈ 4 分钟

参考

简短的解释：按照业务范围建立独立的服务，多个服务组成一个完整的业务模型，各服务之间通过RPC，HTTP等方式通信。
适合在记录型系统和交互型系统中使用。

下面是详细的说明。

微服务(Microservices Architecture)

微服务的概念源于2014年3月Martin Fowler所写的一篇文章Microservices。

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
不同服务通过一些轻量级交互机制来通信，例如 RPC、HTTP 等.

  1. 遵循职责单一原则（Single Responsibility Principle）
  2. 服务间的消息通信：
  • 同步消息 REST：同步消息就是客户端需要保持等待，直到服务器返回应答。
  • 异步消息：客户端不需要一直等待服务应答，有应答后会得到通知。一般采用AMQP, STOMP, MQTT 这三种通讯协议
  • 消息格式：JSON, XML, Thrift, ProtoBuf, Avro

微服务架构的一些通用特性

  1. 通过服务实现应用的组件化(Componentizationvia Services)：
    微服务架构中将组件定义为可被独立替换和升级的软件单元，在应用架构设计中通过将整体应用切分成可独立部署及升级的微服务方式进行组件化设计。
  2. 围绕业务能力组织服务(Organizedaround Business Capabilities)：
    微服务架构采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的（如：既管应用，也管数据库）、强搭配的DevOps开发运维一体化团队，通常这些团队不会太大（如：亚马逊的“Two pizzateam”- 不超过12人）。51c2253a.png
  3. 产品而非项目模式(Productsnot Projects)：
    传统的应用模式是一个团队以项目模式开发完整的应用，开发完成后就交付给运维团队负责维护；微服务架构则倡导一个团队应该如开发产品般负责一个“微服务”完整的生命周期，倡导“谁开发，谁运营”的开发运维一体化方法。
  4. 智能端点与管道扁平化(Smartendpoints and dumb pipes)：
    微服务架构主张将组件间通讯的相关业务逻辑/智能放在组件端点侧而非放在通讯组件中，通讯机制或组件应该尽量简单及松耦合。RESTful HTTP协议和仅提供消息路由功能的轻量级异步机制是微服务架构中最常用的通讯机制。
  5. “去中心化”治理(DecentralizedGovernance)：
    整体式应用往往倾向于采用单一技术平台，微服务架构则鼓励使用合适的工具完成各自的任务，每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。微服务的技术标准倾向于寻找其他开发者已成功验证解决类似问题的技术。
  6. “去中心化”数据管理(DecentralizedData Management)：
    微服务架构倡导采用多样性持久化(PolyglotPersistence)的方法，让每个微服务管理其自有数据库，并允许不同微服务采用不同的数据持久化技术。
  7. 基础设施自动化(InfrastructureAutomation)：
    云化及自动化部署等技术极大地降低了微服务构建、部署和运维的难度，通过应用持续集成和持续交付等方法有助于达到加速推出市场的目的。
  8. 故障处理设计(Designfor failure)：
    微服务架构所带来的一个后果是必须考虑每个服务的失败容错机制。因此，微服务非常重视建立架构及业务相关指标的实时监控和日志机制。
  9. 演进式的设计(EvolutionaryDesign)：
    微服务应用更注重快速更新，因此系统的设计会随时间不断变化及演进。微服务的设计受业务功能的生命周期等因素影响。如某应用是整体式应用，但逐渐朝微应用架构方向演进，整体式应用仍是核心，但新功能将使用应用所提供的API构建。再如在某微服务应用中，可替代性模块化设计的基本原则，在实施后发现某两个微服务经常必须同时更新，则这很可能意味着应将其合并为一个微服务。

微服务的一些常见误解

66d21730.png

微服务架构与SOA架构的比较

20e2ccb1.png 微服务架构强调的是系统按业务边界做细粒度的拆分和部署。这是和SOA的区别之一

一个简单的微服务应用例子：航班预订应用

340e3861.png 将航班预订应用划分为预订航班、时间表查询、计算票价、分配座位、管理奖励、更新客户、调整库存七个微服务实施。

哪些应用会从微服务收益

  1. 记录型系统(System of Record)将从微服务方法中获益最多。例如可将大型应用按相对独立的业务功能分解成若干个微服务实现。
    指传统的应用系统，对应用所关注领域的信息进行增删改查作为应用的核心能力。如CRM、ERP、OA等系统。记录型系统使用的往往是一些传统的经典IT技术构建，往往更难改变，其集成难度也较高。

  2. 交互型系统(System of Engagement)也将受益于微服务方法，例如渠道应用可以应用“后端服务前端”的模式实现。
    指以与用户交互为主要目的而开发的应用系统。如各种移动应用、微信、微博等等。交互型系统更多地会采用现代的各种新技术语言及运行时部署，具体高度的敏捷性，通过简单的现代化连接即可实现集成。

  3. 分析型系统(System of Insight)则可能对微服务受益不多。其他架构模式如管道及过滤模式可能更适用于分析型系统。

优点：

  1. 每个服务都比较简单，只关注于一个业务功能。
  2. 微服务架构方式是松耦合的，可以提供更高的灵活性。
  3. 微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题。
  4. 每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度。
  5. 微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。
  6. 独立部署，灵活扩展
  7. 资源的有效隔离
    微服务设计的原则之一，就是每一个微服务拥有独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的接口来完成。这样有效避免了服务之间争用数据库和缓存资源所带来的问题。

缺点：

  1. 增加开发和测试的复杂度
  2. 增加的开发难度，需要保证不同服务之间数据的一致性，引入了分布式事务和异步补偿机制
  3. 运维开销及成本增加：整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成，可能需要40~60个进程。
  4. 必须有坚实的DevOps开发运维一体化技能：开发人员需要熟知运维与投产环境，开发人员也需要掌握必要的数据存储技术如NoSQL，具有较强DevOps技能的人员比较稀缺，会带来招聘人才方面的挑战。
  5. 隐式接口及接口匹配问题：把系统分为多个协作组件后会产生新的接口，这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。在实际环境中，一个新品发布可能被迫同时发布大量服务，由于集成点的大量增加，微服务架构会有更高的发布风险。
  6. 代码重复：某些底层功能需要被多个服务所用，为了避免将“同步耦合引入到系统中”，有时需要向不同服务添加一些代码，这就会导致代码重复。
  7. 分布式系统的复杂性：作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题。
  8. 异步机制：微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，其实现机制会变得复杂化。
  9. 可测性的挑战：在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。经典微服务往往不太重视测试，更多的是通过监控发现生产环境的异常，进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。

关于微服务架构的取舍

  • 在合适的项目，合适的团队，采用微服务架构收益会大于成本。
  • 微服务架构有很多吸引人的地方，但在拥抱微服务之前，也需要认清它所带来的挑战。
  • 需要避免为了“微服务”而“微服务”。
  • 微服务架构引入策略 – 对传统企业而言，开始时可以考虑引入部分合适的微服务架构原则对已有系统进行改造或新建微服务应用，逐步探索及积累微服务架构经验，而非全盘实施微服务架构。

SOA服务架构(Service Oriented Architecture)

面向服务架构。SOA的精髓是严格的松散耦合，不允许直接访问其它服务的数据，大家按照一个契约或标准（service interface）来进行交流。
是一种粗粒度，松耦合的服务架构，针对的是异构系统之间的通信。
优点：

  1. 松耦合
  2. 组件化
  3. 可复用
  4. 跨平台、跨语言
  5. 易上手

单体架构(Monolithic Architecture )

企业级的应用一般都会面临各种各样的业务需求，而常见的方式是把大量功能堆积到同一个单体架构中去。比如：常见的ERP、CRM等系统都以单体架构的方式运行，同时由于提供了大量的业务功能，随着功能的升级，整个研发、发布、定位问题，扩展，升级这样一个“怪物”系统会变得越来越困难。

缺点：

  1. 项目过于臃肿
    当大大小小的功能模块都集中在同一项目的时候，整个项目必然会变得臃肿，让开发者难以维护。

  2. 资源无法隔离
    整个单体系统的各个功能模块都依赖于同样的数据库、内存等资源，一旦某个功能模块对资源使用不当，整个系统都会被拖垮。

  3. 无法灵活扩展
    当系统的访问量越来越大的时候，单体系统固然可以进行水平扩展，部署在多台机器上组成集群：
    但是这种扩展并非灵活的扩展。比如我们现在的性能瓶颈是支付模块，希望只针对支付模块做水平扩展，这一点在单体系统是做不到的。

    421168fb.png