2018-11-22 20:30 门头沟学院 Java

关注

3天快速了解微服务架构之概述

《Spring Cloud与Docker微服务实战》读书笔记

什么是微服务架构？

它解决的哪些问题？

它具有哪些特点？

如何实现？

聊聊架构的演变

集中式架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。

一个归档包（如war包）所包含所有功能的应用程序，通常称为单体应用。

优点：

容易部署
测试
项目初期可以很好的满足需求

缺点：

随着需求增加，越来越臃肿，可维护性，灵活性降低
复杂性高
技术债务
部署频率低
可靠性差（任何错误都可能导致整个服务崩溃）
扩展能力受限（为硬件做处妥协）
阻碍技术创性（更换技术栈代价昂贵）

垂直拆分

根据业务功能将单体应用进行拆分。

优点：

系统拆分实现了流量分担，解决了并发问题
可以针对不同模块进行优化
方便水平扩展，负载均衡，容错率提高

缺点：

系统间相互独立，会有很多重复开发工作，影响开发效率

分布式服务

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式调用是关键。

优点：

将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率

缺点：

系统间耦合度变高，调用关系错综复杂，难以维护

SOA/服务治理

SOA全英文是Service-Oriented Architecture，中文意思是中文面向服务编程，是一种思想，一种方法论，一种分布式的服务架构。soa也称为服务治理。

以前出现了什么问题？

服务越来越多，需要管理每个服务的地址
调用关系错综复杂，难以理清依赖关系
服务过多，服务状态难以管理，无法根据服务情况动态管理

服务治理要做什么？

服务注册中心，实现服务自动注册和发现，无需人为记录服务地址
服务自动订阅，服务列表自动推送，服务调用透明化，无需关心依赖关系
动态监控服务状态监控报告，人为控制服务状态

优点：

降低用户成本，用户不需要关心各服务之间是什么语言的、不需要知道如果调用他们，只要通过统一标准找数据总线就可以了。
程序之间关系服务简单
可识别哪些程序有问题

缺点：

服务间会有依赖关系，一旦某个环节出错会影响较大
服务关系复杂，运维、测试部署困难，不符合DevOps思想

微服务架构

那么问题来了，什么是微服务架构？

微服务架构就是用来解决上述问题的架构

微服务架构风格是一种将单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中服务间通信采用轻量级通信机制。

微服务架构则是将单个的整体应用程序分割成更小的项目关联的独立的服务。一个服务通常实现一组独立的特性或功能，包含自己的业务逻辑和适配器。各个微服务之间的关联通过暴露api来实现。这些独立的微服务不需要部署在同一个虚拟机，同一个系统和同一个应用服务器中。

微服务和soa 有什么不同？

网上的答案通常是，微服务是细粒度的soa。并不是很准确。SOA更加关注业务规模范围，而微服务更加关注应用规模范围。微服务组件和soa组件区别在于细粒度不同。

微服务架构的优点：

每个服务都比较简单，只关注于一个业务功能。
微服务架构方式是松耦合的，可以提供更高的灵活性。
微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题。
每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度。
微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。

微服务架构的缺点：

微服务的一些想法在实践上是好的，但当整体实现时也会呈现出其复杂性。

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

该文章将的很清楚https://blog.csdn.net/moonpure/article/details/79768621

微服务设计原则

摘自Spring Cloud与docker微服务架构实战

单一职责原则

单一职责原则指的是一个单元（类、方法或者服务等）只应关注整个系统功能中单独、有界限的一部分。单一职责原则可以帮助我们更优雅地开发、更敏捷地交付。

服务自治原则

服务自治是指每个微服务应当具备独立的业务能力、依赖与运行环境。在微服务架构中，服务是独立的业务单元，应该与其他服务高度解耦。每个服务从开发、测试、构建、部署，都应当可以独立运行，而不应该依赖其他服务。

轻量级通信原则

微服务之间应该通过轻量级通信机制进行交互。轻量级通信机制应该具备两点：首先是它的体量较轻；其次是它应该是跨语言、跨平台的。例如我们所熟悉的REST协议，就是一个典型的“轻量级通信机制”；而例如Java的RMI协议则就不符合轻量级通信要求，应该它绑定了Java语言。
微服务架构中，常用的协议有REST、AMQP、STOMP、MQTT等。

微服务粒度

微服务的粒度是难点，也常常是争论的焦点。应当使用合理的粒度划分微服务，而不是一味将服务做小。代码量的多少不能作为微服务划分的依据，因为不同的服务本身的业务复杂性不同，代码量也不同。在微服务的设计阶段，就应确定其边界。微服务之间应该相对独立并保持松耦合。领域驱动设计中的“界限上下文”可作为微服务边界、确定微服务粒度的重要依据。