企业网站建设的好处,傻瓜式建站软件下载,免费3d动画制作软件,关于网站建设要花多少钱接前一篇文章#xff1a;软考 系统架构设计师系列知识点之云原生架构设计理论与实践#xff08;12#xff09; 所属章节#xff1a;
第14章. 云原生架构设计理论与实践 第3节 云原生架构相关技术 14.3.2 云原生微服务 1. 微服务发展背景
过去开发一个后端应用最为直接的方…接前一篇文章软考 系统架构设计师系列知识点之云原生架构设计理论与实践12 所属章节
第14章. 云原生架构设计理论与实践 第3节 云原生架构相关技术 14.3.2 云原生微服务 1. 微服务发展背景
过去开发一个后端应用最为直接的方式就是通过单一后端应用提供并集成所有的服务即单体模式。随着业务发展与需求不断增加单体应用功能愈发复杂参与开发的工程师规模可能由最初几个人发展到十几人应用迭代效率由于集中式研发、测试、发布、沟通模式而显著下滑。为了解决由单体应用模型衍生的过度集中式项目迭代流程微服务模式应运而生。
微服务模式将后端单体应用拆分为松耦合的多个子应用每个子应用负责一组子功能。这些子应用称为“微服务”多个“微服务”共同形成了一个物理独立但逻辑完整的分布式微服务体系。这些微服务相对独立通过解耦研发、测试与部署流程提高整体迭代效率。此外微服务模式通过分布式架构将应用水平扩展和冗余部署从根本上解决了单体应用在拓展性和稳定性上存在的先天架构缺陷。但也要注意到微服务模型也面临着分布式系统的典型挑战如何高效调用远程方法、如何实现可靠的系统容量预估、如何建立负载均衡体系、如何面向松耦合系统进行集成测试、如何面向大规模复杂关联应用的部署与运维。
在云原生时代云原生微服务体系将充分利用云资源的高可用和安全体系让应用获得更有保障的弹性、可用性与安全性。应用构建在云所提供的基础设施与基础服务之上充分利用云服务所带来的敏捷性、稳定性降低应用架构的复杂性等。云原生的微服务体系也将帮助应用架构全面升级让应用天然具有更好的可观测性、可控制性、可容错性等特性。
2. 微服务设计约束
相较于单体应用微服务架构的架构转变在提升开发、部署等环节灵活性的同时也提升了在运维、监控环节的复杂性。设计一个优秀的微服务系统应遵循以下设计约束
1微服务个体约束
一个设计良好的微服务应用所完成的功能在业务领域划分上应是相互独立的。与单体应用强行绑定语言与技术栈相比这样做的好处是不同业务域有不同的技术选择权。比如推荐系统采用Python实现效率可能比Java要高效得多。从组织上来说微服务对应的团队更小开发效率也更高。“一个微服务团队一顿能吃掉两张披萨饼”、“一个微服务应用应当能至少两周完成一次迭代”都是对如何正确划分微服务在业务领域边界的隐喻和标准。总结来说微服务的“微”并不是为了微而微而是按照问题域对单体应用做合理拆分。
进一步地微服务也应具备正交分解特性在职责划分上专注于特定业务并将之做好即SOLID原则中单一职责原则Single Responsibility PrincipleSRP。如果当一个微服务修改或者发布时不应该影响到同一系统里另一个微服务的业务交互。
2微服务与微服务之间的横向关系
在合理划分好微服务间的边界后主要从微服务的可发现性和可交互性处理服务间的横向关系。微服务的可发现性是指当服务A发布和扩缩容的时候依赖服务A的服务B如何在不重新发布的前提下如何能够自动感知到服务A的变化这里需要引入第三方服务注册中心来满足服务的可发现性特别是对于大规模微服务集群服务注册中心的推送和扩展能力尤为关键。微服务的交互性是指服务A采用什么样的方式可以调用服务B。由于服务自治的约束服务之间的调用需要采用与语言无关的远程调用协议比如REST协议很好地满足了“与语言无关”和“标准化”两个重要因素但在高性能场景下基于IDL的二进制协议可能是更好的选择。另外目前业界大部分微服务实践往往没有达到HATEOAS启发式的REST调用服务与服务之间需要通过事先约定接口来完成调用。为了进一步实现服务与服务之间的解耦为服务体系中需要有一个独立的元数据中心来存储服务的元数据信息服务通过查询该中心来理解发起调用的细节。伴随着服务链路的不断变长整个微服务系统也就变得越来越脆弱因此面向失败设计的原则在微服务体系中就显得尤为重要了。对于微服务应用个体限流、熔断、隔仓、负载均衡等增强服务韧性的机制成为了标配。为进一步提升系统吞吐能力、充分利用好机器资源可以通过协程、Rx模型、异步调用、反压等手段来实现。
3微服务与数据层之间的纵向约束
4全局视角下的微服务分布式约束 更多微服务设计约束详情请看下回。
