目前还是有不少的中小企业把自己的业务工作负载放置在本地数据中心,面对着日益增大的业务量,本地数据中心开始慢慢凸显出一些弊端,难以满足企业新型业务的需求,并且购买以及更新设备都需要企业提前支出一大笔资金,很多中小企业难以承受其中的压力,通过迁移上云我们可以避免本地数据中心面临的一些问题。
当企业使用 AWS,可以实现按需高效、安全地运行资源,只需短短几小时,就能使企业以远胜从前的效率,敏捷地实现创新,再无需等待数月时间。那企业上云,想更快更好地将原有服务做迁移,制定迁移计划需要注意哪些问题?本篇文章将与你系统探讨 AWS 迁移模式。
边界清晰的好处
我们更多的是两种架构模式的一个混合,比如A和B一起是一个部署单元,C是另外一个独立的部署单元,这种情况往往是因为C非常重要,他并发的访问量非常大,或者它的需求变更比较频繁。将C拆分出来的有以下几个好处:
-
资源倾斜
-
使用弹力设计模式:比如重试,熔断,降级
-
使用特殊技术:比如Go语言
-
具备独立代码库:有独立团队和运维人员,和A和B的运行期做到隔离不互相影响
这四点正是服务架构所关注的,它是基于非功能纬度的视角来看待拆分这件事情的,他关注的不是系统架构的逻辑边界,更多的关注的是应用程序行为的分隔。
那为什么不把A和B都拆成一个独立的部署单元?
这会带来更多的好处,也会带来额外的成本,架构应该是可以演进的,在业务发展的早期,应该关注系统架构的逻辑边界,保持逻辑边界的清晰和关系的正确,随着业务量的增加,逐步在做拆分,这是组合应用DDD和微服务架构带来的最大的好处。
在单体架构中,保持架构逻辑边界不被突破是有一定难度。如果逻辑边界不清晰,在需要服务器拆分的时候,就未必能拆得出来了。另外没有人一下子就可以把逻辑边界定义正确,即使这个上下文定义的不太正确,在DDD 聚合根 这个概念可以保障我们能够演进出更适合的上下文。
DDD界限上下文内部通过实体和值对象来对领域概念进行建模, 一组实体和值子对象归属于一个聚合根 。那按DDD要求
聚合根用来保证内部实体规则的正确性和数据的一致性
外部对象只能通过ID来引用聚合根,不能引用聚合根内部的实体
聚合根之间不能共享一个数据库事务,它们之间的数据一致性需要通过最终的一致性来保障
有了聚合根,基于这些约束,未来可以根据需要把聚合根升级为上下文,甚至拆分成微服务都是比较容易的。
