网站建设公司怎么办,做网站的公司简介,如何做网站域名,制作作业平台网站的设计我们知道微服务是一种理念#xff0c;没有确切的定义和边界#xff0c;好比设计原则#xff0c;是属于抽象的概念。在定义不明确的情况下谈划分也是一种各说各话#xff0c;具体问题需要具体分析#xff0c;所以这篇文章谈到的划分也不是绝对标准#xff0c;仅供参考。有… 我们知道微服务是一种理念没有确切的定义和边界好比设计原则是属于抽象的概念。在定义不明确的情况下谈划分也是一种各说各话具体问题需要具体分析所以这篇文章谈到的划分也不是绝对标准仅供参考。 有人说微幅不难难的是服务的划分虽然我持保留意见。但是从侧面也反应了划分具有一定的困难。这里的矛盾在于粒度。如果粒度太大了分和不分似乎都差不多如果粒度太小了聚合、发布、调用链、调试等都是坑。 以下谈到的拆分是前人经验的总结我罗列了三种行家的拆分姿势每个的的经验和视野不同各有偏颇我在这里更多的是谈共鸣和感受希望对你有所启发。1.姿势一 新浪微博微服务专家胡忠想从纵横两个维度来划分简单粗暴1.1 纵向拆分 从业务维度进行拆分。标准是按照业务的关联程度来决定关联比较密切的业务适合拆分为一个微服务而功能相对比较独立的业务适合单独拆分为一个微服务。1.2 横向拆分 从公共且独立功能维度拆分。标准是按照是否有公共的被多个其他服务调用且依赖的资源独立不与其他业务耦合。 纵向以业务为基准关系铁的在一起横向功能独立的在一起。我想如果拆分这么简单你有底气拆敢拆吗所以我们又继续比对一下其他专家的言论。2.姿势二 阿里的小伙伴从综合的维度来看部分维度和上面会有重合。2.1 服务拆分要迎合业务的需要 充分考虑业务独立性和专业性避免以团队来定义服务边界从而出现“土匪”抢地盘影响团队信任。 这个维度和上面的类似但是强调的是业务和团队成员的各自独立性对上面是一种很好的补充。2.2 拆分后的维护成本要低于拆分前 这里的维护成本包括人力、物力、时间。 这里的成本对大部分中小团队来说都是必须要考虑的重要环节如果投入和收益不能成正比或者超出领导的预算或者市场窗口那么先进的技术就是绊脚石千万不要迷恋技术所谓工程师思维千万要不得。2.3 拆分不仅仅是架构的调整组织结构上也要做响应的适应性优化 确保拆分后的服务由相对独立的团队负责维护。 这句话怎么理解呢传统的团队划分是按照产品部、前端、后端横向划分微服务化以后的团队可能就会是吃一张披萨饼的人数产品、前端、后端被归类到服务里面以服务为中心来分配人数。2.4 拆分最有价值的结果是提高了系统的可扩展性 把具有不同扩展性要求的服务拆分出来分别进行部署降低成本提高效率。比如全文搜索服务。 这点和上面的按功能独立性来拆分有点类似功能独立其实就是面向可扩展性。2.5 考虑软件发布频率 比如把20%经常变动的部分进行抽离80%不经常变动的单独部署和管理。说白了就是按照8/2原则进行拆分。这个拆分的好处很明显可以尽可能的减少发布产生的后遗症比如用户体验、服务相互干扰等。 但是这里有一个问题假如20%的服务分属于不同的业务层面那该怎么办所以这里的拆分应该有个优先级在拆分相互冲突的时候应该要优先考虑权重比较高的那个。3.姿势三 资深技术专家李运华在他的架构书中给出的拆分3.1 基于业务逻辑 将系统中的业务按照职责范围进行识别职责相同的划分为一个单独的服务。这种业务优先的方式在前面两种姿势当中都出现过可见是最基本最重要的划分方式没有之一。3.2 基于稳定性 将系统中的业务模块按照稳定性进行排序。稳定的、不经常修改的划分一块将不稳定的经常修改的划分为一个独立服务。比如日志服务、监控服务都是相对稳定的服务可以归到一起。这个很类似上面提到的2/8原则80%的业务是稳定的。 至此你会发现服务的拆分真的没有绝对的标准只有合理才是标准。3.3 基于可靠性 同样将系统中的业务模块按照可靠性进行排序。对可靠性要求比较高的核心模块归在一起对可靠性要求不高的非核心模块归在一块。 这种拆分的高明可以很好的规避因为一颗老鼠屎坏了一锅粥的单体弊端同时将来要做高可用方案也能很好的节省机器或带宽的成本。3.4 基于高性能 同上将系统中的业务模块按照对性能的要求进行优先级排序。把对性能要求较高的模块独立成一个服务对性能要求不高的放在一起。比如全文搜索商品查询和分类秒杀就属于高性能的核心模块。4.姿势盘点 以上不同拆分姿势各有千秋异曲同工对业务逻辑均不约而同的放在第一位。对业务模块的稳定性和可靠性对功能的独立性、可扩展性都有相似的看法强调拆分应该是多选而不是单选。具体情况具体分析可以自由灵活排列组合。 如果你把上面的划分角度背下来了拿去现场套可能还会遇到矛盾或争议。1.业务矛盾 假如我们按照业务来划分根据粒度大小可能存在以下两种第一种分为商品、交易、用户3个服务第二种分为商品、订单、支付、物流、买家、卖家6个服务。 3 VS 6这该怎么办 如果你的团队只有9个人那么分成3个是合理的如果有18个人那么6个服务是合理的。这里引入团队成员进行协助拆分。 可见拆分的姿势不是单选而是多选的。这个时候必须要考虑团队成员数量。 在拆分遇到争议的时候一般情况下我们增加一项拆分条件虽然不是充要条件但至少我们的答案会更加接近真理。 除了业务可能存在争议其他的划分也会有争议比如一个独立的服务到底需要多少人员的配置2.三个火枪手(人员配置) 上面提到的人员数量配置这里为什么是9和18呢(这里的团队配置参考李云华前辈提到的三个火枪手的观点) 换一种问法为什么说是三个人分配一个服务当然成员主要是后端人员假设是1个人请个假、生个病都不行。一个人会遇到单点的问题所以不合理。假设是2个人终于有备份了但是抽离一个后剩下1个压力还是很大不合理。假设是3个人抽离一个还有2个在。而且数字3是个稳定而神奇数字用得好事半功倍。特别是遇到技术讨论3个人相对周全如果是2个可能会各持己见带有自我的偏见和盲区。 那么这个3是不是就是稳定的数量呢 假设你做的是边开飞机边换引擎的重写工作那么前期3个人都可能捉襟见肘。但是到了服务后期你可能1个就够了。 所以3在我的理解应该是一个基准线不同的时间段会有上下波动但是相对稳定。原文地址https://www.cnblogs.com/jackyfei/p/10856427.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
