
课程咨询: 400-996-5531
投诉建议: 400-111-8989
认真做教育 专心促就业
微服务架构开发技术随着互联网的不断发展而被越来越多的程序员掌握,今天我们就通过案例分析来简单了解一下,微服务架构技术应用需要掌握哪些知识点。
轻量级的通讯微服务主张使用轻量级去构建通讯机制,我认为是使用基于HTTP协议的API资源,一般是RESTfulAPI。不过现在正式投入生产的应用中,微服务之间的通讯绝不止于RESTful,虽然HTTP协议相对来说较为简单,但它在传输的性能和可靠性也存在比较大的局限,特别是JSON在序列化也较弱。所以在微服务内部通讯会使用更多的RPC框架,例如Netty,gRPC,阿里的dubbo协议等等,甚至还可以使用消息中间件来完成通讯传输。究竟我们的服务应该选择RPC还是RESTful,在后面的章节会进行讨论。
基于业务能力构建文中强调了服务的规划和划分,是基于业务进行构建,这一点非常的重要,是业务而非技术驱动微服务的设计,这一个观点从而也推动了领域驱动设计(DDD)的发展,越来越多的人尝试将领域驱动设计引入微服务架构的设计中。例如:在电商的系统中,我们划分服务更多考虑的是业务,例如:用户服务,商品服务,订单服务等等,这个在后面划分服务的章节将会再进行讨论。
独立部署在以往的大型独体项目中,部署和发布永远是高悬头顶的达摩克利斯之剑,某一个模块的错误都可能让整个系统崩塌。但是微服务的一个关键原则是:每一个服务都是系统的组件,均可以独立的进行部署,团队之间是不需要特别的进行协调,当我们开发和部署一个服务时,我们只需要确保测试和部署好一个服务,如果真的把它搞砸了,也不会把整个系统都搞砸。当然,一个服务挂掉了不会把整个系统都搞砸,还需要建立在一个好的微服务治理上,这个问题我们在后面的章节中也会讨论。
原来的单体服务需要整个技术团队都是独立的架构团队去进行管理,统一的架构,统一的技术栈,统计的存储。而在微服务中得益于服务的拆分,人员的拆分,所以在实施微服务将不再受限于系统的技术栈,无论是开发的语言,数据库,缓存都是可以进行自由的选择。从理论上来说,微服务是一种通过网络协议的跨平台调用,只要规定好服务的接口和服务的网络协议,服务本身的技术都是可以自由选择的。对每个系统本身来说,是小的中心化管理,但是,如果从整个微服务的系统架构来说,我们需要考虑到整个微服务的注册,发现,降级,监控,编排等等,这也衍生了我们对微服务更多的“管理中心”,例如我们会使用SpringCloud或Dubbo框架进行管理。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。