网站新闻列表页面代码,安徽建站管理系统开发,wordpress自定义文章,淘宝客怎么做网站前言最近几年微服务很火#xff0c;大家都在建设微服务#xff0c;仿佛不谈点微服务相关的技术#xff0c;都显得不是那么主流了。近几年见识到身边朋友的很多公司和团队都在尝试进行微服务的改变#xff0c;但很多团队并没有实际微服务踩坑经验#xff0c;很多团队甚至强… 前言最近几年微服务很火大家都在建设微服务仿佛不谈点微服务相关的技术都显得不是那么主流了。近几年见识到身边朋友的很多公司和团队都在尝试进行微服务的改变但很多团队并没有实际微服务踩坑经验很多团队甚至强行为了微服务而去微服务最终写成一个大型的分布式单体应用就是改造后的系统既没有微服务的快速扩容灵活发布的特性也让原本的单体应用失去了方便开发部署容易的特性项目拆为多份开发部署复杂度都提高了不得不说是得不偿失。作者亲身经历和参与几个大型项目微服务的改造和建设。所以想作为实践者跟大家分享关于微服务的实际经验帮助大家了解微服务的优缺点从而可以结合自身业务做出更加合适的选择作为本篇文章的三个主题例如什么是微服务为什么要用微服务微服务解决什么问题又引入了什么问题使用微服务应该要遵循哪些原则什么样的情况你不应该使用微服务PS因为市面上太多对如果使用微服务框架工具的教程所以本篇只是一篇关于微服务的总体概述性文章不涉及各种微服务框架的安装和使用教程我们只谈论微服务本身的设计模式的优缺点和适合应用的场景一什么是微服务为什么要用微服务什么是微服务熟悉的同学可以直接跳过简单举例看军事新闻的同学应该都知道一艘航空母舰作战能力虽然很强但是弱点太明显就是防御能力太差单艘的航空母舰很少单独行动通常航空母舰战斗群才是主要军事力量你可以把单艘航母理解为的单体应用防御差机动性不好把航母战斗群调度复杂维护费用高理解为微服务。大部分的开发者经历和开发过单体应用无论是传统的 Servlet JSP还是 SSM还是现在的 SpringBoot它们都是单体应用那么长期陪伴我们的单体应用有什么弊端我们是面临了什么问题导致我们要抛弃单体应用转向微服务架构个人总结主要问题如下部署成本高无论是修改1行代码还是10行代码都要全量替换改动影响大风险高不论代码改动多小成本都相同因为成本高风险高所以导致部署频率低无法快速交付客户需求当然还有例如无法满足快速扩容弹性伸缩无法适应云环境特性等问题但我们不一一详谈了以上的问题都是微服务架构要解决的问题至于具体是怎么解决的我们先放到后面再聊二微服务解决什么问题又引入了什么问题我们先看看微服务能带给我们什么微服务架构的特点针对特定服务发布影响小风险小成本低频繁发布版本快速交付需求低成本扩容弹性伸缩适应云环境我们知道一个朴素的理念没有任何事物是完美的任何东西都有两面性有得必有失那么在选择微服务在解决了快速响应和弹性伸缩的问题同时它又给我们带来了什么问题个人总结如下分布式系统的复杂性部署测试和监控的成本问题分布式事务和CAP的相关问题系统应用由原来的单体变成几十到几百个不同的工程会所产生例如包括服务间的依赖服务如何拆封内部接口规范数据传递等等问题尤其是服务拆分需要团队熟悉业务流程懂得取舍要保证拆分的粒度服务既符合“高内聚低耦合”的基本原则还要兼顾业务的发展以及公司的愿景要还要说服团队成员为之努力并且积极投入在多方中间取得平衡。对于分布式系统部署测试和监控都需要大量的中间件来支撑而且中间件本身也要维护原先单体应用很简单的事务问题 转到分布式环境就变得很复杂分布式事务是采用简单的重试补偿机制还是采用二阶段提交协议等强一致性方法来解决就要取决对业务场景的熟悉加上反复的权衡了相同问题还包括对 CAP 模型的权衡总之微服务对团队整体的技术栈水平整体要求更高三使用微服务应该遵循哪些原则古人云兵马未动粮草先行。建设微服务是需要建立长远规划不是像写CMS那样建好数据库表然后就开始干活这样十有八九是会失败的。我们要进行微服务改造前架构师要提前做好规划我们把这里分为三步前期阶段设计阶段技术阶段前期阶段大致要做好如下事情和多方充分沟通确保能符合客户和组织的需求并且得到认同和团队沟通让队友开发/测试/运维理解并且积极投入和业务部门沟通指定版本计划和上线时间设计阶段参考 Sam Newman 的著作《微服务设计》单微服务必须要满足以下的条件才符合微服务的基本要求标准的 REST 风格接口基于 HTTP 和 JSON 格式独立部署避免共享数据库避免因为数据库而影响整个分布式系统业务上的高内聚减少依赖从设计上要避免服务过大或者太小庞大的分布式系统需要强大基础设施来支撑微服务涉及哪些基础设施CI/CD和自动化分布式系统几乎不可能通过人工手动发布虚拟化技术要保证微服务运行环境隔离目前行业主流的是使用 Docker 容器日志聚合全链路监控高度可观察和分析诊断问题说了那么多那什么样的情况下你的团队不适合建设微服务请勿对号入座开发团队不具备自主性所在组织对开发团队限制非常多具体请参考 康威定律团队不熟悉业务无法识别出服务的边界进行合理的拆分请参考 DDD 领域驱动设计 总结微服务设计其实是很早就有的设计思想因为随着虚拟化技术的崛起微服务可以低成本的实现所以也开始流行和兴起。微服务的内涵很深其中就包括自动化去中心化独立性等等其中细节无法用一篇文章概述清楚我们在做技术选型或者方案的时候尽可能多去了解技术的本身和起源再结合我们业务的特点进行更好的选择。个人知识有限不喜勿喷对于微服务你又有什么不同的看法呢欢迎来留言进行讨论和交流 原文链接https://www.cnblogs.com/xiao2shiqi/p/11298663.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
