|
|
|
|
移动端

1.5 微服务的设计原则

《深入理解Spring Cloud与微服务构建》第1章微服务简介,本章介绍什么是微服务、为什么需要微服务、微服务的优缺点和挑战,并且将单体架构的系统和微服务架构的系统进行了比较。本节为大家介绍微服务的设计原则。

作者:方志朋来源:人民邮电出版社|2018-03-06 15:05

技术沙龙 | 6月30日与多位专家探讨技术高速发展下如何应对运维新挑战!


1.5 微服务的设计原则

软件设计就好比建筑设计。Architect这个词在建筑学中是“建筑师”的意思,而在软件领域里则是“架构师”的意思,可见它们确实有相似之处。无论是建筑师还是架构师,他们都希望把作品设计出自己的特色,并且更愿意把创造出的东西被称为艺术品。然而现实却是,建筑设计和软件设计有非常大的区别。建筑师设计并建造出来的建筑往往很难有变化,除非拆了重建。而架构师设计出来的软件系统,为了满足产品的业务发展,在它的整个生命周期中,每一个版本都有很多的变化。

软件设计每一个版本都在变化,所以软件设计应该是渐进式发展。软件从一开始就不应该被设计成微服务架构,微服务架构固然有优势,但是它需要更多的资源,包括服务器资源、技术人员等。追求大公司所带来的技术解决方案,刻意地追求某个新技术,企图使用技术解决所有的问题,这些都是软件设计的误区。

技术应该是随着业务的发展而发展的,任何脱离业务的技术是不能产生价值的。在初创公司,业务很单一时,如果在LAMP单体构架够用的情况下,就应该用LAMP,因为它开发速度快,性价比高。随着业务的发展,用户量的增加,可以考虑将数据库读写分离、加缓存、加复杂均衡服务器、将应用程序集群化部署等。如果业务还在不断发展,这时可以考虑使用分布式系统,例如微服务架构的系统。不管使用什么样的架构,驱动架构的发展一定是业务的发展,只有当前架构不再适合当前业务的发展,才考虑更换架构。

在微服务架构中,有三大难题,那就是服务故障的传播性、服务的划分和分布式事务。在微服务设计时,一定要考虑清楚这三个难题,从而选择合适的框架。目前比较流行的微服务框架有Spring社区的Spring Cloud、Google公司的Kubernetes等。不管使用哪一种框架或者工具,都需要考虑这三大难题。为了解决服务故障的传播性,一般的微服务框架都有熔断机制组件。另外,服务的划分没有具体的划分方法,一般来说根据业务来划分服务,领域驱动设计具有指导作用。最后,分布式事务一般的解决办法就是两阶段提交或者三阶段提交,不管使用哪一种都存在事务失败,导致数据不一致的情况,关键时刻还得人工去恢复数据。总之,微服务的设计一定是渐进式的,并且是随着业务的发展而发展的。


喜欢的朋友可以添加我们的微信账号:

51CTO读书频道二维码


51CTO读书频道活动讨论群:365934973

【责任编辑:book TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

超级网管员——网络管理

本书全面深入地介绍了在网络的日常管理中,网络管理员必须掌握的知识,包括系统基本管理、性能调优、故障恢复、域控制器管理、存储资源管理...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊