Category: MS Design Princinple
2000 年,Robert C. Martin 给架构师们总结出了一套原则来指导大家进行软件设计,Michael Feathers 随后按首字母将其总结成 SOLID 原则。从那时起,面向对象的 SOLID 设计原则就不断出现在相关书籍当中,并成为业界广为人知的指导方针:单一职责原则、开 / 闭原则、里氏替换原则、接口隔离原则、依赖倒置原则。 Single responsibility principle Open/closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle 在过去的这二十年里,软件开发领域一直在快速演进,特别是近几年云原生和微服务的发展,在微服务体系下,“SOLID 原则是否适合现代软件工程”引起了广泛讨论。
微服务是⼀种分布式架构,系统内各部分(服务)被部署为单独的应用程序,并通过某种远程访问协议进⾏通讯。分布式应⽤的挑战之⼀就是如何管理远程服务的可用性和它们的响应。本⽂主要探讨服务的响应时间对系统的影响和应对。
体会到微服务带来好处的同时,很多公司也明显感受到微服务化带来的一系列让人头疼的问题。 本文是笔者对自己多年微服务化经历的总结。如果你正准备做微服务转型,或者在微服务化过程中遇到了困难。此文很可能会帮到你!
1. 前言 上一篇中梳理介绍了微服务架构的特点和优势,也明确说微服务架构是现代软件开发中解决生产力的一种模式。微服务可以大家加速现代企业中软件开发效率、软件稳定性,扩展性。
1. 最佳实践 微服务架构,多“微”才合适? 微服务到底该多大?如何设计微服务的粒度? 如何更好地干掉微服务架构复杂性? 我大概总结了三个关键词,分别是引入、异构、冗余。 B站在微服务治理中的探索与实践 7个阶段模型,帮助微服务架构落地! 这里提供了三种策略给大家参考,如图所示: 第一种 Cream Scoop Strategy 冰淇淋勺策略:是 Martin Flower 提出的一种策略,也被称为扼杀者方法。可以想象有一大桶冰淇淋,这桶冰淇淋就代表现有的架构,可以用勺子从桶中挖出你们想要的冰淇淋,这个挖出的部分就是要做拆分的服务。最终可以将大桶冰淇淋挖出一个个独立的服务,这里服务包含不同的业务逻辑。这种方式是逐渐修改原有系统,并且逐步对服务进行拆分试错然后过度到单独的资源上运行。每次拆分对系统的影响较小,但是整个系统的拆分和重构需要较长时间。 第二种 乐高法策略(搭积木),把原有的系统想象成一大块乐高积木,我们只需要往上面添加小的乐高积木模块就行了,添加的小模块就是一个个微服务。这样一来就不用对老产品进行调整,新的功能通过微服务的方式实现并且集成到老的产品中。不过需要通过一种能够让微服务与老产品联系的方法,这里会使用到接口编程以及适配器模式。 第三种是 nuclear 策略,和策略的名字一样我们需要对老旧系统推到重来,重新打造微服务架构,说起来容易这里需要花费大量分析和重构的时间,这个周期比较长,成本也是较高的。
网易考拉(以下简称考拉)是网易旗下以跨境业务为主的综合型电商,自2015年1月9日上线公测后,业务保持了高速增长,这背后离不开其技术团队的支撑。微服务化是电商IT架构演化的必然趋势,网易考拉的服务架构演进也经历了从单体应用走向微服务化的整个过程。 以下整理自网易考拉陶杨在近期Apache Dubbo Meetup上的分享。
蚂蚁金服(当时还是支付宝)从 2013 年起就运行在单元化架构上,除了具备异地容灾能力外,还能做到异地多活,可随时在多城市、多数据中心调配流量。基于单元流量调配机制,可实现大规模集群的蓝绿发布、灰度仿真环境,为充分验证业务正确性、降低故障提供了基础条件。相应地,微服务体系也必须具备单元内收敛、单元间可控路由等能力,来支撑单元化技术架构的落地。本文根据玄霄 2018 年上海 QCon 演讲内容整理。
移动终端的开发变得越来越复杂,随之而来的是对 C 端动态化要求越来越高。动态化需要对 C 端里的基础配置、运营资源进行灵活的管理。如何在版本快速迭代过程中,满足业务场景的高效灵活变更?传统的解决方案无法满足这种复杂场景,美团点评基于自身移动运营的实践,打造了稳定、灵活、高效的运营配置平台。本文根据美团点评高级架构师蒋国宝在 QCon 上海的演讲整理而成。
2016 年下半年开始,FreeWheel 开始将其业务系统从 Rails 单体应用逐步迁移到微服务,同时技术栈从 Rails 改为 Golang,两年之后,整个迁移接近尾声,FreeWheel 业务系统技术团队对外分享了它们在微服务化过程中的经验。