精华内容
下载资源
问答
  • 微服务架构设计

    2019-01-02 11:57:00
    微服务架构设计 原文:微服务架构设计微服务 软件架构是一个包含各种组织的系统组织,这些组件包括 Web服务器, 应用服务器, 数据库,存储, 通讯层), 它们彼此或和环境存在关系。系统架构的目标是解决...
    原文:微服务架构设计

    微服务

           软件架构是一个包含各种组织的系统组织,这些组件包括 Web服务器, 应用服务器, 数据库,存储, 通讯层), 它们彼此或和环境存在关系。系统架构的目标是解决利益相关者的关注点。

    image

    Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizations.

    (设计系统的组织,其产生的设计和架构等价于组织间的沟通结构。)

    Monolithic架构

    2016102722


    Monolithic比较适合小项目,优点是:

    开发简单直接,集中式管理, 基本不会重复开发

    功能都在本地,没有分布式的管理开销和调用开销。它的缺点也非常明显,特别对于互联网公司来说(不一一列举了):

    开发效率低:所有的开发在一个项目改代码,递交代码相互等待,代码冲突不断

    代码维护难:代码功能耦合在一起,新人不知道何从下手

    部署不灵活:构建时间长,任何小修改必须重新构建整个项目,这个过程往往很长

    稳定性不高:一个微不足道的小问题,可以导致整个应用挂掉

    扩展性不够:无法满足高并发情况下的业务需求

    微服务架构

            微服务是指开发一个单个小型的但有业务功能的服务,每个服务都有自己的处理和轻量通讯机制,可以部署在单个或多个服务器上。微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说,如果每个服务都要同时修改,那么它们就不是微服务,因为它们紧耦合在一起;如果你需要掌握一个服务太多的上下文场景使用条件,那么它就是一个有上下文边界的服务,这个定义来自DDD领域驱动设计。

    相对于单体架构和SOA,它的主要特点是组件化、松耦合、自治、去中心化,体现在以下几个方面:

    • 一组小的服务
      服务粒度要小,而每个服务是针对一个单一职责的业务能力的封装,专注做好一件事情。

    • 独立部署运行和扩展
      每个服务能够独立被部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏,使得快速交付和应对变化成为可能。

    • 独立开发和演化
      技术选型灵活,不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。服务与服务之间采取与语言无关的API进行集成。相对单体架构,微服务架构是更面向业务创新的一种架构模式。

    • 独立团队和自治
      团队对服务的整个生命周期负责,工作在独立的上下文中,自己决策自己治理,而不需要统一的指挥中心。团队和团队之间通过松散的社区部落进行衔接。

            我们可以看到整个微服务的思想就如我们现在面对信息爆炸、知识爆炸是一样的:通过解耦我们所做的事情,分而治之以减少不必要的损耗,使得整个复杂的系统和组织能够快速的应对变化。

    我们为什么采用微服务呢?

    "让我们的系统尽可能快地响应变化" - Rebecca Parson

    让我们的系统尽可能快地去响应变化。其实几十年来我们一直在尝试解决这个问题。如果一定要在前面加个限制的话,那就是低成本的快速响应变化。上世纪90年代Kent Beck提出要拥抱变化,在同期出现了诸多轻量级开发方法(诸如 XP、Scrum);2001年敏捷宣言诞生,之后又出现了精益、看板等新的管理方式。如果说,这些是为了尽快的响应变化,在软件开发流程和实践方面提出的解决方案,那么微服务架构就是在软件技术和架构层面提出的应对之道。

    image

    Autonomous
    A Microservice is a unit of functionality; it provides an API for a set of capabilities oriented around a business domain or common utility

    Isolated
    A Microservice is a unit of deployment; it can be modified, tested and deployed as a unit without impacting other areas of a solution

    Elastic
    A Microservice is stateless; it can be horizontally scaled up and down as needed

    Resilient
    A Microservice is designed for failure; it is fault tolerant and highly available

    Responsive
    A Microservice responds to requests in a reasonable amount of time

    Intelligent
    The intelligence in a system is found in the Microservice endpoints not ‘on the wire’

    Message Oriented
    Microservices rely on HTTP or a lightweight message bus to establish a boundary between components; this ensures loose coupling, isolation, location transparency, and provides the means to delegate errors as messages

    Programmable
    Microservices provide API’s for access by developers and administrators

    Composable
    Applications are composed from multiple Microservices

    Automated
    The lifecycle of a Microservice is managed through automation that includes development, build, test, staging, production and distribution

    服务之间如何通信

    2016102726

     

    一般同步调用比较简单,一致性强,但是容易出调用问题,性能体验上也会差些,特别是调用层次多的时候。RESTful和RPC的比较也是一个很有意 思的话题。一般REST基于HTTP,更容易实现,更容易被接受,服务端实现技术也更灵活些,各个语言都能支持,同时能跨客户端,对客户端没有特殊的要 求,只要封装了HTTP的SDK就能调用,所以相对使用的广一些。RPC也有自己的优点,传输协议更高效,安全更可控,特别在一个公司内部,如果有统一个 的开发规范和统一的服务框架时,他的开发效率优势更明显些。就看各自的技术积累实际条件,自己的选择了。而异步消息的方式在分布式系统中有特别广泛的应用,他既能减低调用服务之间的耦合,又能成为调用之间的缓冲,确保消息积压不会冲垮被调用方,同时能 保证调用方的服务体验,继续干自己该干的活,不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱,需要接受数据最终一致性;还有就是后台服务一般要 实现幂等性,因为消息发送出于性能的考虑一般会有重复(保证消息的被收到且仅收到一次对性能是很大的考验);最后就是必须引入一个独立的broker,如 果公司内部没有技术积累,对broker分布式管理也是一个很大的挑战。

     

    2016102729

    微服务优点

    • 每个微服务都很小,这样能聚焦一个指定的业务功能或业务需求。
    • 微服务能够被小团队单独开发,这个小团队是2到5人的开发人员组成。
    • 微服务是松耦合的,是有功能意义的服务,无论是在开发阶段或部署阶段都是独立的。
    • 微服务能使用不同的语言开发。
    • 微服务允许容易且灵活的方式集成自动部署,通过持续集成工具,如Jenkins, bamboo 。
    • 一个团队的新成员能够更快投入生产。
    • 微服务易于被一个开发人员理解,修改和维护,这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
    • 微服务允许你利用融合最新技术。
    • 微服务只是业务逻辑的代码,不会和HTML,CSS 或其他界面组件混合。
    • 微服务能够即时被要求扩展。
    • 微服务能部署中低端配置的服务器上。
    • 易于和第三方集成。
    • 每个微服务都有自己的存储能力,可以有自己的数据库。也可以有统一数据库。

    微服务架构的缺点

    • 微服务架构可能带来过多的操作。
    • 需要DevOps技巧 (http://en.wikipedia.org/wiki/DevOps).
    • 可能双倍的努力。
    • 分布式系统可能复杂难以管理。
    • 因为分布部署跟踪问题难。
    • 当服务数量增加,管理复杂性增加。

    需要考虑的问题

    • 单个微服务代码量小,易修改和维护。但是,系统复杂度的总量是不变的,每个服务代码少了,但服务的个数肯定就多了。就跟拼图游戏一样,切的越碎,越难拼出整幅图。一个系统被拆分成零碎的微服务,最后要集成为一个完整的系统,其复杂度肯定比大块的功能集成要高很多。
    • 单个微服务数据独立,可独立部署和运行。虽然微服务本身是可以独立部署和运行的,但仍然避免不了业务上的你来我往,这就涉及到要对外通信,当微服务的数量达到一定量级的时候,如何提供一个高效的集群通信机制成为一个问题。
    • 单个微服务拥有自己的进程,进程本身就可以动态的启停,为无缝升级的打好了基础,但谁来启动和停止进程,什么时机,选择在哪台设备上做这件事情才是无缝升级的关键。这个能力并不是微服务本身提供的,而是需要背后强大的版本管理和部署能力。
    • 多个相同的微服务可以做负载均衡,提高性能和可靠性。正是因为相同微服务可以有多个不同实例,让服务按需动态伸缩成为可能,在高峰期可以启动更多的相同的微服务实例为更多用户服务,以此提高响应速度。同时这种机制也提供了高可靠性,在某个微服务故障后,其他相同的微服务可以接替其工作,对外表现为某个设备故障后业务不中断。同样的道理,微服务本身是不会去关心系统负载的,那么什么时候应该启动更多的微服务,多个微服务的流量应该如何调度和分发,这背后也有一套复杂的负载监控和均衡的系统在起作用。
    • 微服务可以独立部署和对外提供服务,微服务的业务上线和下线是动态的,当一个新的微服务上线时,用户是如何访问到这种新的服务?这就需要有一个统一的入口,新的服务可以动态的注册到这个入口上,用户每次访问时可以从这个入口拿到系统所有服务的访问地址。这个统一的系统入口并不是微服务本身的一部分,所以这种能力需要系统单独提供。
    • 还有一些企业级关注的系统问题,比如,安全策略如何集中管理?系统故障如何快速审计和跟踪到具体服务?整个系统状态如何监控?服务之间的依赖关系如何管理?等等这些问题都不是单个微服务考虑的范畴,而需要有一个系统性的考虑和设计,让每个微服务都能够按照系统性的要求和约束提供对应的安全性,可靠性,可维护性的能力。

    image

    API为什么很重要

    •服务价值的精华体现
    •可靠、可用、可读
    •只有一次机会

    image

    实现一个API网关作为所有客户端的唯一入口。API网关有两种方式来处理请求。有些请求被简单地代理/路由到合适的服务上,其他的请求被转给到一组服务。

    19193548_Vczr.jpg

    相比于提供普适的API,API网关根据不同的客户端开放不同的API。比如,Netflix API网关运行着客户端特定的适配器代码,会向客户端提供最适合其需求的API。

    API网关也可以实现安全性,比如验证客户端是否被授权进行某请求。

    设计要素

    •Version
    •RequstID
    •Auth&Signature
    •RateLimit
    •Docs
    •ErrorCode&Message

    image

    微服务治理

    •按需伸缩
    –部署与监控运维成本
    •独立部署
    –机器数量与部署成本
    •业务独立
    –服务依赖、治理,版本管理、事务处理
    •技术多样性
    –环境部署成本、约定成本

    •运行状态治理
    –监控、限流、SLA、LB、日志分析
    •服务注册与发现
    •部署
    –快速、复制、扩容
    –单机开发
    •调用
    –安全、容错、服务降级、调用延时

    image

    image

    服务容错

         当企业微服务化以后,服务之间会有错综复杂的依赖关系,例如,一个前端请求一般会依赖于多个后端服务,技术上称为1 -> N扇出. 在实际生产环境中,服务往往不是百分百可靠,服务可能会出错或者产生延迟,如果一个应用不能对其依赖的故障进行容错和隔离,那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中,某个单一后端一旦发生延迟,可能在数秒内导致所有应用资源(线程,队列等)被耗尽,造成所谓的雪崩效应(Cascading Failure),严重时可致整个网站瘫痪。

    1125005

    服务依赖

    1125006

    服务框架

    1. 服务注册、发现、负载均衡和健康检查,假定采用进程内LB方案,那么服务自注册一般统一做在服务器端框架中,健康检查逻辑由具体业务服务定制,框架层提供调用健康检查逻辑的机制,服务发现和负载均衡则集成在服务客户端框架中。
    2. 监控日志,框架一方面要记录重要的框架层日志、metrics和调用链数据,还要将日志、metrics等接口暴露出来,让业务层能根据需要记录业务日志数据。在运行环境中,所有日志数据一般集中落地到企业后台日志系统,做进一步分析和处理。
    3. REST/RPC和序列化,框架层要支持将业务逻辑以HTTP/REST或者RPC方式暴露出来,HTTP/REST是当前主流API暴露方式,在性能要求高的场合则可采用Binary/RPC方式。针对当前多样化的设备类型(浏览器、普通PC、无线设备等),框架层要支持可定制的序列化机制,例如,对浏览器,框架支持输出Ajax友好的JSON消息格式,而对无线设备上的Native App,框架支持输出性能高的Binary消息格式。
    4. 配置,除了支持普通配置文件方式的配置,框架层还可集成动态运行时配置,能够在运行时针对不同环境动态调整服务的参数和配置。
    5. 限流和容错,框架集成限流容错组件,能够在运行时自动限流和容错,保护服务,如果进一步和动态配置相结合,还可以实现动态限流和熔断。
    6. 管理接口,框架集成管理接口,一方面可以在线查看框架和服务内部状态,同时还可以动态调整内部状态,对调试、监控和管理能提供快速反馈。Spring Boot微框架的Actuator模块就是一个强大的管理接口。
    7. 统一错误处理,对于框架层和服务的内部异常,如果框架层能够统一处理并记录日志,对服务监控和快速问题定位有很大帮助。
    8. 安全,安全和访问控制逻辑可以在框架层统一进行封装,可做成插件形式,具体业务服务根据需要加载相关安全插件。
    9. 文档自动生成,文档的书写和同步一直是一个痛点,框架层如果能支持文档的自动生成和同步,会给使用API的开发和测试人员带来极大便利。Swagger是一种流行Restful API的文档方案。

    微服务系统底座

    一个完整的微服务系统,它的底座最少要包含以下功能:

    • 日志和审计,主要是日志的汇总,分类和查询

    • 监控和告警,主要是监控每个服务的状态,必要时产生告警

    • 消息总线,轻量级的MQ或HTTP

    • 注册发现

    • 负载均衡

    • 部署和升级

    • 事件调度机制

    • 资源管理,如:底层的虚拟机,物理机和网络管理

    以下功能不是最小集的一部分,但也属于底座功能:

    • 认证和鉴权

    • 微服务统一代码框架,支持多种编程语言

    • 统一服务构建和打包

    • 统一服务测试

    • 微服务CI/CD流水线

    • 服务依赖关系管理

    • 统一问题跟踪调试框架,俗称调用链

    • 灰度发布

    • 蓝绿部署

    容器(Docker)与微服务

    •容器够小
    –解决微服务对机器数量的诉求
    •容器独立
    –解决多语言问题
    •开发环境与生产环境相同
    –单机开发、提升效率
    •容器效率高
    –省钱
    •代码/image一体化
    –可复用管理系统
    •容器的横向与纵向扩容
    –可复制
    –可动态调节CPU与内存

    容器(Docker)与微服务

    •Image管理
    •系统安全管理
    •授权管理
    •系统成熟度
    •社区成熟度

    开发方式影响

    随着持续交付概念推广以及Docker容器普及,微服务将这两种理念和技术结合起来,形成新的微服务+API + 平台的开发模式,提出了容器化微服务的持续交付概念。
    下图传统Monolithic的DevOps开发队伍方式:

    ms

    这种整体型架构要求产品队伍横跨产品管理 Dev开发 QA DBA 以及系统运营管理,而微服务架构引入以后,如下图:

    ms2

    微服务促进了DevOps方式的重组,将一个大臃肿的整体产品开发队伍切分为根据不同微服务的划分的产品队伍,以及一个大的整体的平台队伍负责运营管理,两者之间通过API交互,做到了松耦合隔绝。

    20161027214

    010

    • 首先需要考虑构建DevOps能力,这是保证微服务架构在持续交付和应对复杂运维问题的动力之源;
    • 其次保持服务持续演进,使之能够快速、低成本地被拆分和合并,以快速响应业务的变化;
    • 同时要保持团队和架构对齐。微服务貌似是技术层面的变革,但它对团队结构和组织文化有很强的要求和影响。识别和构建匹配架构的团队是解决问题的另一大支柱。
    • 最后,打造持续改进的自组织文化是实施微服务的关键基石。只有持续改进,持续学习和反馈,持续打造这样一个文化氛围和团队,微服务架构才能持续发展下去,保持新鲜的生命力,从而实现我们的初衷。

        微服务的实施是有一定的先决条件:基础的运维能力(如监控、快速配置、快速部署)需提前构建,否则就会陷入如我们般被动的局面。推荐采用基础设施及代码的实践,通过代码来描述计算和网络基础设施的方法,使得图案度i可以快速安全的搭建和处理由新的配置代替的服务器,服务器之间可以拥有更高的一致性,降低了在“我的环境工作,而你的环境不工作”的可能,也是为后续的发布策略和运维提供更好的支撑。

    013

    由于Docker引入,不同的微服务可以使用不同的技术架构,比如Node.js Java Ruby Python等等,这些单个的服务都可以独立完成交付生命周期,如下:

    ms21

    微服务案例

    Netflix的微服务架构如下,着重全球分发 高可扩展性和可用性:

    ms212

    Twitter的微服务架构,注重高效的可扩展的数据中心:

    ms2123

    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    希望对您系统架构,软件项目开发,运维管理,系统架构与研发管理体系, 信息安全, 企业信息化等有帮助。 其它您可能感兴趣的文章:
    云计算参考架构几例
    微服务与Docker介绍
    互联网直播平台架构案例一
    高可用架构案例一
    某互联网公司广告平台技术架构
    某大型电商云平台实践
    云计算参考架构几例
    移动应用App测试与质量管理一
    全面的软件测试
    著名ERP厂商的SSO单点登录解决方案介绍一
    软件项目风险管理介绍
    企业项目化管理介绍
    智能企业与信息化之一
    由企业家基本素质想到的
    敏捷软件质量保证的方法与实践
    构建高效的研发与自动化运维
    IT运维监控解决方案介绍
    IT持续集成之质量管理
    人才公司环境与企业文化
    企业绩效管理系统之平衡记分卡
    企业文化、团队文化与知识共享
    高效能的团队建设
    餐饮连锁公司IT信息化解决方案一

    如有想了解更多软件研发 , 系统 IT集成 , 企业信息化,项目管理,企业管理 等资讯,请关注我的微信订阅号:

    MegadotnetMicroMsg_thumb1_thumb1_thu[1]

     


    作者:Petter Liu
    出处:http://www.cnblogs.com/wintersun/
    本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
    该文章也同时发布在我的独立博客中-Petter Liu Blog

    posted on 2019-01-02 11:57 NET未来之路 阅读(...) 评论(...) 编辑 收藏

    转载于:https://www.cnblogs.com/lonelyxmas/p/10207768.html

    展开全文
  • 微服务架构设计.pdf

    2021-01-28 16:04:54
    微服务架构设计
  • 从最简单的定义来看,微服务架构是将逻辑域划分为独立服务的同时开发软件的行为。 在过去的六年中,我听说微服务方法学以惊人的速度增长。 每个人都在谈论微服务!还有另一个转变,那就是从云计算到微服务。〜Steve ...
    96f2a1eaf5f843af5e75dc68cc3660f7.png

    Photo by Tatiana Latino on Unsplash

    注意:本文内容是我的见解,而非我的雇主或其他实体的见解。

    什么是微服务?

    从最简单的定义来看,微服务架构是将逻辑域划分为独立服务的同时开发软件的行为。 在过去的六年中,我听说微服务方法学以惊人的速度增长。 每个人都在谈论微服务!

    还有另一个转变,那就是从云计算到微服务。〜Steve Singh(Concur)

    大多数尚未使用微服务的工程师都生活在整体代码库中。 生活在一个单一的世界中并不都是一件坏事,并且可以使用许多已建立的架构模式来构建应用程序。 归根结底,您必须选择最适合您的应用的应用,而不是流行的应用。 如果将微服务作为体系结构模式,则逻辑和数据流在服务之间的分解和分布方式之间存在一些根本差异。 让我们快速看一下下面的两个示例。

    524300f98358ba4030951eb5c3657122.png

    Microservices vs Monoliths

    通过分解整体并分离层,您可以交换/更新单个层,而无需部署整个代码库! 不过,这仅仅是开始。

    现在,您可以创建物理抽象层以分解代码和逻辑。 创建这些域可以使工程师轻松找到并修复功能。 这也允许独立部署域。 这些抽象也可以通过诸如nuget / npm / etc之类的Package References共享代码。

    微服务引入的另一个概念是隔离的数据存储。 微服务中的数据存储有两种思路:隔离数据库或共享数据库。 如果它是共享数据库,则建议按架构拆分域。 虽然,如果它是一个隔离的数据库,您可以决定是否要为不同的域使用不同类型的数据存储。 您的客户域可能使用Sql Server数据库,而您的订单历史记录域可能使用MongoDB。 同样,使用正确的工具完成正确的工作!

    网关:您不得通过

    可以控制基础结构暴露的一种方法是网关。 可以将它视为控制服务的数据/逻辑流的一种方法,或者将一个或多个域包装在一起的一种方法。 我使用网关将外部OAuth身份验证转换为我的内部基础结构可以理解的标准共享密钥,以使其轻巧。 对于那些熟悉领域驱动设计的人,我最好的建议是将每个微服务视为有界上下文,并将每个网关都视为域。

    d473129eb2cfc93edec6232e0fd20df2.gif

    实施网关有很多好处:

    • 使用网关来分解身份验证类型或访问方法。
    • 使用网关来拆分域。
    • 使用网关按用户类型,区域或租户指示流量。
    • 使用网关将外部流量与管理流量分开。

    混合代码? 嗯?

    微服务架构的一个很酷的方面是,您的整个基础架构不必全部都是相同的结构甚至是相同的语言! 将应用程序的逻辑域分解为微服务可以使您能够使用正确的工具来完成正确的工作。 如果您的代码库是.net,但您确实希望在Elixir中编写基础结构的线程密集型部分,没问题! 这也有其自身的问题,但我确实鼓励混合水平的团队组成。 不同的平台和语言都有各自的优缺点。 如果做得对,这可以带来很多好处:

    • 跨团队的交叉授粉模式
    • 向您的工程师介绍新技术
    • 允许感兴趣的工程师突破常规并使用其他语言进行实验

    让我们分解一个例子

    系好安全带,这可能需要一点时间。 让我们更深入一点,设计一个理论架构。 在不深入研究杂草的情况下,让我们定义一个跨越几个重要边界的非常简单的商务应用程序。

    问题:我们想构建一个公共API来跟踪客户,允许下订单并保留订单的历史记录。 我们希望允许该API支持现代的前端,移动应用程序和第三方集成。 我们还知道,用户在高峰时段浏览产品的频率要比下订单的频率高100倍。 用户创建订单时,我们要向他们发送电子邮件。

    a1a3395d3743e80d714d13785d17d49e.png

    An example microservice architecture to support a commerce application.

    解决方案:上面的解决方案乍看之下似乎很复杂,但对我来说几乎没有。 我的第一步是定义我的域,在本例中是产品,订单,历史记录和客户。 我不希望我的服务集成必须单独处理每个服务,否则可能会导致业务逻辑出现一些其他严重问题。

    但是为什么要有两个网关? 这是两倍。 我想避免网关做太多事情,但是它也允许集成有选择地实现功能。 这也使我可以在购物周围部署更新,而不必部署与客户相关的更新。 我们要避免网关变得单一。

    每个服务都应该是自包含的,并且不应跨越域壁垒。 这也包括数据存储。 如果需要合并两个服务之间的逻辑,请在网关中将调用绑定在一起。 "不要越过溪流!"

    c5f08404db0393f02403fec8653a20cd.gif

    要提到的一件事是电子邮件集成。 这是参数的一个示例:服务或包引用。 我个人认为,应该将诸如SendGrid之类的电子邮件集成包装在基础结构服务中,以便您可以标准化处理电子邮件的方式。 电子邮件集成的很多因素使简单的软件包参考变得复杂。 让我们举几个……

    • 批量发送电子邮件?
    • 交货时间表?
    • 缓存的电子邮件模板?
    • 客户品牌?
    • 电子邮件记录?

    如果有这些,则可能需要考虑将其包装在服务中,并将元数据存储在该服务的数据库中。

    好了,最后一项…数据位于一堆不同的数据库中,那么报告呢? 我有一个建议给你; 每个独立的数据库都应具有自己的ETL过程,该过程可以对数据进行非规范化并将其存储在数据湖中。 我还建议任何BI工具都应直接从数据湖查询。 有很多方法可以给猫咪贴皮,但是我喜欢看到人们提出的创新解决方案。

    优点缺点

    选择微服务有很多优点和缺点,您必须确定最适合您的解决方案。

    现在您有100个问题:在过去采用微服务时,我看到的一个结果是,开发人员试图使一切都成为微服务。 我认为,出于抽象的考虑,它离抽象有点太近了。 对于某些人来说这可能是个滑坡,除非您有成熟的团队,否则这可能成为不利条件。

    除非您的系统过于复杂而无法作为一个整体进行管理,否则不要考虑使用微服务。 大多数软件系统应构建为单体应用程序。 请务必注意该整体中的良好模块化,但不要尝试将其分为单独的服务。-Martin Fowler

    独立部署:一个巨大的(有点明显)优势是单个服务的部署可以打破大型"爆炸式"部署。 一旦功能完成并针对生态系统的其余部分进行了集成测试,您就可以部署它,而不必部署整个堆栈。

    隔离域:我想向人们介绍的一个概念是安全域概念。 在设计微服务的拓扑时,应考虑这一点。 控制访问权限和服务的生存方式,是使服务在需要的地方保持简单,但在其他地方保持健壮和安全的一种很好的方法。 以这种方式控制访问,也不再需要向"授权"工程师抽象超敏感服务。

    eacef8c39dc37e6293995b8f1fbd8546.png

    Secure Domains using Infrastructure as Security

    通过基础架构实现安全性:将应用程序划分为微服务的一个真正令人敬畏的结果是,能够将敏感或管理服务抽象到防火墙后,并且仅将对它的访问权限列入白名单。 这意味着,例如,电子邮件微服务不可公开访问,但是您的公共服务可以使用它。 这大大减少了应用程序的公共空间。

    共享基础结构:沿着这种模式,您应该假设,您在域堆栈中越走越远,服务就可以变得越"共享"。 并非总是如此,但绝对是多数。 电子邮件服务就是一个很好的例子。 与允许每个服务与SendGrid通信(例如)相反,我将构建一个微服务来承担该责任。 所有需要电子邮件功能的服务都需要与该服务进行对话,以便我可以控制谁可以访问。 它还为我提供了一个处理品牌或模板的位置!

    数据库是独占还是共享?

    进入微服务时,您首先要做出的决定之一是选择每个服务使用一个数据库还是跨服务使用共享数据库。 就个人而言,我更喜欢每个服务使用一个数据库来解耦数据并创建更容易的部署管道。 如果选择这种方式,则需要确定如何跨数据库整合外键或查找数据。 如果您需要将这些数据放在一起进行分析或报告,通常可以将其ETL放入数据仓库并整理数据。

    示例:如果您有一个用于客户的微服务和一个用于订单历史记录的微服务,则需要将CustomerId与订单历史记录一起存储。 当ETL运行此历史记录记录时,您将预取客户记录并将数据展平以存储在数据池中的表中。

    微服务适合我吗?

    微服务并非适合所有人。 迈出下一步还意味着要做好准备……成功和失败。 这是为工作选择合适的工具。 有时,这意味着您不必选择"热门"技术。 新技术并没有错,但保持公正很重要。

    如果您无法构建整体,那么为什么您认为微服务才是答案?-西蒙·布朗

    7f0bddc80a63f9297b6991e717b425fa.gif

    采用微服务与成熟度和刚性有关。 您必须准备好在部署和数据管道流程中引入一些麻烦,因为使用微服务,您可以独立部署较小的代码单元,并且必须确保一旦部署,它不会破坏现有的任何内容。

    您必须准备好完全采用语义版本控制和包管理。 引入微服务时,我经常听到工程师对软件包管理和"转换版本"的抱怨。 是的,这可能很麻烦,但部署时会有些许痛苦,但会引起一些注意。

    好的,微服务适合我,现在呢?

    有很多策略可以将整体拆分为微服务,我将在另一篇文章中深入介绍。 但是在此之前,让我们介绍一些高层次的兴趣点。 有四个要点要解决,我将按照采用的顺序进行介绍。

    1 突破基础架构服务:将基础级别的功能区域分解为整个集群可以使用的服务,这是打破整体的重要的第一步。

    电子邮件微服务就是一个很好的例子。 您可以轻松引用Sendgrid nuget包并开始发送电子邮件。 但是,如果您想对每封电子邮件应用逻辑(例如将其包装在模板中),该怎么办? 您应该站起来一个微服务,该微服务采用通用的数据合同来发送电子邮件,将其封装在服务内的模板逻辑,并使其完成发送电子邮件的工作。 这也使您能够更改电子邮件提供商/机制并仅部署微服务。

    2 将可重复使用的项目移至"包引用"中:与上面的相同,但不需要扩展名或基于租户的自定义。

    一个示例是与RabbitMQ实例对话的持久队列连接器。 将此功能包装在服务中没有任何意义。 仅创建一个nuget包并允许服务引用它并调用队列就可以了。

    3 识别域服务:识别域可能是进入微服务领域最具挑战性的部分。 开发人员经常为可能(表面上)存在于两个逻辑域之间的业务逻辑块而苦恼。 永远不要重复这种逻辑,如果不能决定,我建议您坚持一个经常问自己的问题:该记录的根数据类型是什么,或者最经常请求哪个域。

    参考上面的购物车示例,例如" GetRecentOrders"之类的调用。 这些数据的根源是历史记录,但由客户提供。 我要做的就是将此呼叫放入"历史记录"服务中,并需要一个CustomerId来获取数据。

    4 识别网关服务:在定义服务拓扑之前,最后一项真正的任务是识别网关。 这可能很困难,因为它是对域进行分组并确定前端(或第三方消费者)如何导航服务的好地方。 但是,您不需要太多的网关。

    这样的一个例子是在逻辑上将您的管理服务分组在" Admin Gateway"后面,并实施更严格的身份验证要求和角色管理。 您甚至可以使用网关将允许使用此网关的IP地址或应用程序列入白名单。

    49b4cf1eaf33c901fb895b478fd4ac64.gif

    由于每种解决方案都不相同,因此很难给出将整体分解为微服务的蓝图。 但我希望您现在有一个制定自己的策略的基础。

    结论

    您是选择使用微服务,无服务器功能还是坚持使用单体服务; 最终,您必须选择最适合您的平台和团队的内容。 您必须考虑到公司采用的技术标准或语言,或者公司希望采用的技术指导。我坚信微服务应该成为构建现代Web服务的标准。

    有许多方法可以沿着微服务道路走,许多人对此事有很强的见解。 不要害怕慢慢地遍历一个模式,看看什么有效,什么无效。 如果它开始不适合您的目标,请进行调整。 不用遗憾,这是我们学习和改进现有模式的方法!

    随着我对无服务器功能的了解越来越多,肯定有一个地方可以填补微服务的空白。 但是,在某些情况下,也可以完全取代它,例如处理来自第三方服务(例如Twilio)的Web挂钩。 即用即弃模式是学习无服务器并防止微服务执行过多操作的绝对完美方法。 但这是我们应该在另一篇文章中探讨的内容。

    (本文翻译自Chris Fryer的文章《Microservice Architecture & Design》,参考:https://medium.com/@cfryerdev/microservice-architecture-design-2ac7eaae532)

    展开全文
  • 微服务架构设计模式与CAP定理

    万次阅读 热门讨论 2020-09-22 23:01:09
    微服务架构设计模式与CAP定理 前言        hello 大家好,我是一名Java后端开发的程序猿。由于国庆假期已经来了,所以我打算把这一星期的时间用来好好提升下自己的技术水平。...

    微服务架构设计模式与CAP定理

    前言

           hello 大家好,我是一名Java后端开发的程序猿。由于国庆假期已经来了,所以我打算把这一星期的时间用来好好提升下自己的技术水平。微服务呢,在大学期间最后一年也学过,但是工作后却用的比较少。为了防止以后公司业务需要用到微服务的时候,我不至于一脸懵然后还要临时学,所以这个国庆打算对微服务进行一个总结。计划是花五天时间。首先我要声明一下,自己是个菜鸟,如果总结的不好或者很糟糕欢迎指出我们大家一起学习。嘿嘿~

    微服务有什么用?

           在早期的互联网开发中,包括现在也有很多的项目都是单体的应用程序。一般这个单体的应用程序是由客户端用户界面,模块和数据库三个部分组成。一般模块会有很多个,最后打成一个包部署在服务器上。在项目的早期阶段,这样的方式会比较容易开发,部署也方便。可是到了后期麻烦可就大了,因为随着用户需求的增加项目功能也会跟着扩展。之前的小应用会变得越来越复杂。一旦出现了Bug就会牵一发而动全身,所以说在单体应用中每个服务的更新和改变都会导致重新部署整个应用,灵活性太低...而分布式就是解决这个问题的。

           微服务顾名思义其实就是把一个庞大的应用程序拆分成一套小而互联的服务。

    SOA架构

           SOA架构它是面向服务的,在单体架构的基础上按照业务功能进一步进行垂直拆分。每一个服务都包含了自己的业务逻辑和多个适配器。把模块拆分再用接口互相通信。就像我们搞开发前后端分离一样,后端使用Responsebody发Json给前端,前端根据后端的接口得到数据。这样在开发的时候,谁都不用等谁先做,各顾其职就好了。SOA架构通常以独立的形式存在于操作系统的进程中,每个服务之间通过网络通信。而微服务的话呢,它其实就是对SOA的拆分进行再拆分。微服务架构比SOA架构拆分的更加彻底。

    微服务架构常见的设计模式

    聚合器微服务设计模式

    在这里插入图片描述

           这个设计模式通过负载均衡使用聚合器调动多个服务,其中每个服务都有自己的缓存服务器和数据库。所有服务的接口都会暴露出来,最后由聚合器把所有检索到的数据进行处理和展示,也可以把数据增加业务逻辑形成新的微服务。这是一种最常见也最简单的设计模式。

    代理微服务设计模式

           这个设计模式和刚刚的图基本上一样我就懒得再画,聚合器换成代理。这个模式主要是由刚才的聚合器模式演变而来的。这种模式在客户端不会聚合数据,而是根据业务需求的差别来调动不同的微服务。代理可以委派请求,也可以进行数据转换工作。每个微服务都是自己独立的缓存和数据库系统。

    链式微服务设计模式

    在这里插入图片描述

           当服务A接收到消息就会去和B通信,然后B又去和C进行通信。因为是链式的,所以服务之间的消息同步传递,在客户端发出请求之后没收到响应的这段时间之内一直都是阻塞的,直到整个链条全部走完响应给客户端。所以说我们在链式服务设计模式的时候就不要让它的服务链太长,不然客户端就会长时间等待。

    分支微服务设计模式

    在这里插入图片描述

           这个设计模式比较像是聚合微服务设计模式还有链式微服务设计模式的结合体。我们可以同时调用两个服务链,客户端发送请求调用服务A的时候,而A就需要调用服务B的同时又要去调用服务C,而服务C又需要去调用服务D。所以就形成了分支微服务模式。

    异步消息传递微服务设计模式

    在这里插入图片描述

           在这里呢,服务A请求服务C的时候,服务C又要去请求服务B。这个时候如果同步就会导致阻塞,所以部分微服务架构就会去采用消息队列来请求响应。在这里呢,C就是一个生产者,然后B是消费者。消息队列就是持久化服务C生产的消息,队列会帮助缓存消息一直到消费服务开始工作

    CAP定理

           CAP定理其实它就是指在一个分布式的系统中,Consistency(一致性),Availability(可用性)和Partition Tolerance(分区容错性)这三者在实际开发中不能同时兼顾。

    Consistency(一致性)

           这个其实就是说用户更新完数据之后操作成功返回客户端,然后所有的节点在同一时间内数据会保持一致,这就是分布式的一致性。

    Availability(可用性)

           这个可用性就是服务一直处于可用的状态,一旦接收用户的请求,服务器就必须给出回应,而且是正常响应时间。保持可用性主要还是为了给客户更好的体验,不会出现什么操作失败,访问链接半天访问不到,访问超时等情况。

    Partition Tolerance(分区容错性)

           其实分区容错性呢就是指单台服务器或者多台服务器出现问题后,其他正常的服务器依然可以正常提供服务。在分布式系统中如果遇到某些结点或者网络分区故障的时候,仍然可以继续对外提供满足一致性和可用性的服务。大多数分布式系统中都会存在多个子网络,然后每个子网络都可以称为一个区。

    取舍策略

           因为在分布式系统中CPA三个特性只能同时满足其中两个特性所以取舍策略就会有三种那就是:CA,CP,AP。

           假如我选择了CA策略,那么就是希望能够使系统同时满足一致性和可用性,但是也放弃了分区容错性。这样一来就不能够再部署子节点,放弃了系统的可扩展性很明显违背了分布式系统的初衷。

           那么,我选择CP呢?那么就是希望系统可以同时满足一致性和分区容错性。所有的更新操作都要等同步完成后才能响应返回结果。一旦发生网络故障或者其他事件的时候牺牲可用性影响客户的体验。

           最后就是AP策略了,这个策略就是希望系统满足分区容错性和可用性。但是每个节点的数据只能为本地应用提供服务,导致全局不一致性。

    展开全文
  • 关于微服务架构的定义众说纷纭,因此我摘取了几个描述的比较清晰的定义在这供参考。 1.网飞(Netflix)架构师给出的定义,所谓微服务架构就是服务导向,松耦合有边界的元素构成的架构,松耦合指的是可以独立更新服务...

    关于微服务架构的定义众说纷纭,因此我摘取了几个描述的比较清晰的定义在这供参考。
    1.网飞(Netflix)架构师给出的定义,所谓微服务架构就是服务导向,松耦合有边界的元素构成的架构,松耦合指的是可以独立更新服务,不会对其他服务造成影响。同时,对于数据库需要适当的拆分,有可能会违反规范。
    Cockcroft defines a microservices architecture as a service‑oriented architecture composed of loosely coupled elements that have bounded contexts.
    Loosely coupled means that you can update the services independently; updating one service doesn’t require changing any other services. If you have a bunch of small, specialized services but still have to update them together, they’re not microservices because they’re not loosely coupled. One kind of coupling that people tend to overlook as they transition to a microservices architecture is database coupling, where all services talk to the same database and updating a service means changing the schema. You need to split the database up and denormalize it.

    2.Martin Fowler则认为微服务架构是一种开发一套小服务的方式(与SOA不同),服务间通过一些轻量级的方式通信,如HTTP(这也是为什么REST API近年来这么火)方式。这些围绕业务能力搭建的服务可以独立并且自动化的发布。因为微服务没有一个明确的核心,因此可以用不同的语言和存储技术来开发。
    In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

    Chris Richardson在他的书(design patterns)中给出了一个较为详细可操作性的关于微服务架构的阐述,通过三个象限的维度拓展应用,即多实例、路由和负载均衡、根据功能拆分,微服务的最小单元——服务,仅仅是一个功能的实现。微服务用大白话来说就是将原先的单体架构拆分成一个个小服务,粒度细化。
    说到微服务,就避不开网飞这家公司,网飞是较早实现微服务架构的公司并且开源了一套完整的组件供其他公司使用,有
    服务发现组件:eureka https://github.com/Netflix/eureka
    负载均衡组件:ribbon https://github.com/Netflix/ribbon
    限流熔断组件:Hystrix https://github.com/Netflix/Hystrix
    路由监控组件:zuul https://github.com/Netflix/zuul
    之后,Pivitol公司在这些组件上做了封装,也开发了一些其他组件组成了一套比较成熟完整的微服务生态
    https://github.com/spring-cloud

    目前市面上做微服务还比较流行的组件有
    Web Service客户端: Spring Cloud Feign https://github.com/spring-cloud/spring-cloud-openfeign
    API网关: Spring Cloud Gateway(目标是取代zuul)
    分布式配置中心: Spring Cloud Config
    阿里巴巴早先的微服务解决方案:Apache Dubbo(https://github.com/apache/dubbo)(该项目已通过Apache孵化,成为阿帕奇基金的顶级项目)
    阿里巴巴微服务一站式解决方案:Spring Cloud Alibaba(https://github.com/spring-cloud-incubator/spring-cloud-alibaba

    目前Spring Cloud技术栈的对比如下图,由于Netflex逐渐将组件的开发状态转为维护状态,Pivitol公司可能面临后继乏力的危险,而Spring Cloud Alibaba正在慢慢发力,有可能在未来取代Spring Cloud形成微服务闭环的技术栈。

    Spring Cloud技术栈对比

    那么微服务架构是什么样的呢?
    在Github上有个叫piggymetrics(https://github.com/sqshq/PiggyMetrics)的项目就很简单明了的展示了何为微服务架构,如下图,作者用Spring Boot, Spring Cloud和Docker等技术栈搭起来一个微服务的演示项目,服务与服务之间通过REST API通信,每个服务拥有独立的数据库

    PiggyMetrics微服务架构图

    下图更加详细的展示了微服务所用到的技术栈和各个微服务组件是如何在整个微服务架构中发挥作用的。

    微服务组件的应用

    ZUUL: API路由
    ELK STACK: 日志分析
    HYSTRIX 和 RIBBON:负载均衡和熔断限流
    EUREKA: 服务发现
    TURBINE: 监控大盘
    Spring Cloud Config: 分布式配置中心
    OAuth2: 服务鉴权授权

    微服务带来的好处很多,诸如
    使大型复杂应用可以持续性发布和部署(采用DevOps的方式开发,小团队,多次迭代,快速部署,单次部署风险小)
    服务“微”容易维护(代码量较少,容易理解,开发快)
    服务可以独立拓展(可根据应用的特性部署到不同的机器,例如可以将CPU密集型应用和内存密集型应用部署到不同机器,以充分发挥机器性能)
    服务可以单独部署(松耦合,与其他服务的联系不强,自主性强)
    新技术的采用更为方便(例如可以使用Golang写的OAuth2进行鉴权授权,不需要全部使用同一种语言)
    较强的容错性(Hystrix可以防止“雪崩”的产生,可以隔离故障,也可以根据条件进行服务降级, Ribbon实现软负载均衡,减轻单机压力)

    当然,凡是都有两面性,没有绝对的“银弹”,微服务架构也会带来一些缺点,如
    如何划分服务的边界,根据业务还是根据何种规约
    分布式系统带来的复杂性使得开发、测试和部署都增加难度
    如果发布的特性设计多个服务,需要谨慎和多个团队合作
    采用微服务的时机难以界定
    数据的一致性不好维护
    数据查询难,尤其是涉及到跨数据库

    对此,Chris Richardson也划分了多个架构模式来应对微服务架构所带来的种种问题,可以说好的架构是演化而来的,例如单体架构演化到微服务架构,可以通过应用设计模式、应用基础设施设计模式和基础设施设计模式多方面来解决微服务带来的问题。其他设计模式会在接下来的文章一一道来,我也会写一些相关的代码示例来更加形象展示微服务的实战,我的github地址:https://github.com/Guilai1990?tab=repositories

    参考资料:

    Martin Fowler个人网站 https://www.martinfowler.com/microservices/

    Adopting Microservices at Netflix: Lessons for Architectural Design

    PiggyMetrics的Github

    Chris Richardson —— Microservice Patterns

    Chris Richardson个人网站 https://microservices.io/patterns/microservices.html

    展开全文

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 8,570
精华内容 3,428
关键字:

微服务架构设计