基于微服务架构的系统设计
  摘要：微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。
关键词：微服务；Spring Cloud；基本方法；发展；设计
中图分类号：TP311.11  文献标识码：A
        引言
        微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于 HTTP 协议的 RESTful API）。每个服务都围绕着具
体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，对具体的服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
        1.微服务架构的发展
        近年来，随着互联网行业的迅猛发展，公司或组织业务的不断扩张，需求的快速变化以及用户量的不断增加，传统的单块（Monolithic）软件架构面临着越来越多的挑战，已逐渐无法适应互联网时代对软件的要求。在这一背景下，微服务架构模式(Microservice Architecture Pattern)逐渐流行。它强调将单一业务功能开发成微服务的形式，每个微服务运行在一个进程中；采用HTTP等通信协议和轻量级API实现微服务之间的协作与通信[1]。这些微服务可以使用不同的开发语言以及不同数据存储技术，能够通过自动化部署工具独立发布，并保持最低限制的集中式管理。微服务网关和注册中心区别
        微服务架构 ≈ 模块化开发 + 分布式计算。不管微服务架构的定义怎么样，都是在描述一个核心思想：把大系统拆分成小型系统，把大事化小，以降低系统的复杂性，从而大幅降低系统建设、升级、运维的风险和成本。
        2. 微服务架构与微服务
        “微服务”是一个很糟糕的名字，它导致开发人员创建了许多粒度很小的服务，每个服务
拥有一个单独的 REST 端点。不仅如此，这个名字还暗示了微服务在开发者心目中的重要位置。例如，人们会说“我们可以用微服务来解决这个问题”；我也看到了越来越多的“某某微服务框架”，而实际上，这些框架跟微服务架构不一定有太多联系，它们只是简单的 Web 框架。使用“微服务架构”这个名字会更恰当些。它是一种架构风格，它把一系列协作的服务组织成一个系统来支撑业务[2]。
        常见的微服务组件及概念：
        服务注册，服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地到自己。
        (2) 服务发现，服务调用方从服务注册中心到自己需要调用的服务的地址。 
        (3) 负载均衡，服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，节点选择的工作对服务调用方来说是透明的。
        (4)服务网关，服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能。 
        （5)配置中心，将本地化的配置信息（properties,xml,yaml等）注册到配置中心，实现程序包 在开发、测试、生产环境的无差别性，方便程序包的迁移。 
        （6)API管理，以方便的形式编写及更新API文档，并以方便的形式供调用者查看和测试。
        （7）集成框架，微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够在统一的界面中使用系统。 
        （8）分布式事务，对于重要的业务，需要通过分布式事务技术（TCC、高可用消息服务、最大努力 通知）保证数据的一致性。 
        （9）调用链，记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地到出错点。 
        （10）支撑平台，系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构 更加复杂，那么，就需要将大部分的工作自动化。现在，可以通过 Docker 等工具来中和这些微服务架构带来的弊端。例如持续集成、蓝绿发布、健康检查、性能健康等等。严重点，以我们两年的实践经验，可以这么说，如果没有合适的支撑平台或工具，就不要使用微服务架构。
        3. 微服务架构的优点和缺陷
        微服务的优点和缺陷就像一枚硬币的两面，要根据项目的实际情况合理的决定选用哪种架构。
        3.1微服务的优势显而易见
        (1)避免系统无限膨胀
每个服务都很简单，只关注于一个业务功能，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。
        (2)独立部署
由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。
        (3)微团队独立开发，扁平化管理
由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
        (4)可以通过不同的编程语言与工具进行开发
        不同的模块之间不用关系具体实现。
        更好的扩展性
        单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用
的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。
        (6)容错性
当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。
        3.2微服务架构的一些缺点
        (1)分布式系统的复杂性
作为一种分布式系统，微服务引入了复杂性和其他若干问题，比如网络延迟、容错性、消息序列化、不可靠的网络、异步、版本化、应用层中的负载变化等等。
        (2)代码重复
微服务强调小规模团队独立开发，不建议使用全局的公共类库。会在一定程度上造成代码重复。
        (3)测试繁琐
相比垂直应用架构，微服务的分散部署使测试变得繁琐。
        4.微服务架构最佳实践
        使用分布式和自动化进行微服务运维
        利用分布式系统的性能线性增长和弹性扩容能力，支撑大规模微服务对运维系统带来的冲击。主要的如分布式性能数据和日志采集系统；
        分布式汇总和计算框架；
        分布式文件存储服务；
        分布式日志检索服务等。
        结束语
        构建复杂的应用真的是非常困难。单体式的架构更适合轻量级的简单应用。如果你用它来开发复杂应用，那真的会很糟糕。随着用户需求个性化、产品生命周期变短，微服务架构是未来软件软件架构朝着灵活性、扩展性、伸缩性以及高可用性发展的必然方向。
参考文献
[1] 马丁·福勒. 分析模式. Addison-Wesley. ISBN 0-201-89542-0.
[2] 马丁·福勒; David Rice,Matthew Foemmel,Edward Hieatt,Robert Mee,以及Randy Stafford. 企业应用架构模式.

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。