Scala微服务架构 三

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
云原生网关 MSE Higress,422元/月
简介: 四 Controller层之前我们已经把基层架构搭建好了,那么要如何使用呢?首先看看我的Controller层代码@Singletonclass BMAuthController @Inject()(implicit cc: ControllerComponents, actorSystem...

四 Controller层

之前我们已经把基层架构搭建好了,那么要如何使用呢?
首先看看我的Controller层代码

@Singleton
class BMAuthController @Inject()(implicit cc: ControllerComponents, actorSystem: ActorSystem)
            extends AbstractController(cc) with Circe with CirceJsonapiSupport {

    val entry = PlayEntry()

    def parseJson(jsonString: String) : Json = io.circe.parser.parse(jsonString).right.get
    def decodeJson[T](json: Json)(implicit d: io.circe.Decoder[T]) : T = json.as[T].right.get

    def login = Action(circe.json[RootObject]) { implicit request =>
            request
        import model.request.requestsJsonApiOpt.requestsJsonapiRootObjectReader._
        val tt = fromJsonapi(request.body)
        val reVal = entry.commonExcution(
                SequenceSteps(testStep(tt.reqs.head) :: Nil, None))

        val ctest = company("12", "alfred")
        val ctestj = asJsonApi(ctest)
        println(ctestj)

        val result = asJsonApiResult(reVal.asInstanceOf[userdetailresult])
        Ok(result.asJson)
    }
}

4.1 Controller 的声明

4.1.1 @Inject() 注解

@Inject()(implicit cc: ControllerComponents, actorSystem: ActorSystem)

首先这个@Inject会查询Play的System环境,并将查到的==单例实例==注入到参数中.

4.1.2 AbstractController 特质

官网解释

  • AbstractController: an abstract class extending BaseController with a ControllerComponents constructor parameter that can be injected using constructor injection.

也就是说,这就是BaseController的抽象子类,但是要带有一个ControllerComponents作为构造函数.

4.1.3 Circe 特质

circe是一个Scala的Json解析库.并且目前已经支持Play.
Play的使用方式很简单,首先引入项目:

libraryDependencies += "com.dripower" %% "play-circe" % "2609.1"

然后继承play.api.libs.circe.Circe特质

使用起来也很简单,上面代码的
circe.json[RootObject]
部分就是在使用Circe解析JsonApi的Root部分.

4.1.4 CirceJsonapiSupport 特质

对JsonApi协议的支持,里面主要就是两个隐式,代码如下:

trait CirceJsonapiSupport extends CirceJsonapiEncoders with CirceJsonapiDecoders {
    implicit val circeJsonapiMarshaller = Marshaller.delegate[RootObject, String](
        `application/vnd.api+json`,
        `application/json`,
        ContentTypes.`application/json`
    )(_.asJson.noSpaces)
    implicit val circeJsonapiUnmarshaller = Unmarshaller.delegate[String, RootObject](
        `application/vnd.api+json`,
        `application/json`
    )(decode[RootObject](_).right.get)
}

object CirceJsonapiSupport extends CirceJsonapiSupport

4.2 login 代码解析

对不起,各位,暂时没写!!! ,有兴趣的可以私信我,后期我会补上.

※. 本期语法糖

※.1 Scala的构造函数

学自https://www.w3cschool.cn/scala/scala-constructors.html

今天要说的当然不是大家熟知的构造函数,而是以前我们可能忽略的细节.

class User1(var id: String, var name: String)

class User2(val id: String, val name: String)

class User3(private var id: String,private  var name: String)

class User4(id: String, name: String)

上面代码定义了四个User类,每个类都有两个参数idname,当然,他们构造函数的区别也很明显.那么这几种不同的定义方式,有什么区别呢?

  • User1,定义了可变构造参数,同时编译器会自动生成setter和getter方法,但因为是默认修饰符,所以外部可以直接访问user1.id,或者赋值user1.id("001")
  • User2,因为定义的构造参数是不可变的,所以只会生成getter方法,不会有setter方法,也是默认修饰符,所以外部只可以访问user2.id,无法赋值
  • User3,和User1很像,但是修饰符改为private,所以即便是var的构造参数,也不会生成getter方法和setter方法
  • User4,我们最常用的写法,其实就是private[this] val,也就是说对于自己和伴生类而言是可见的

应杨总要求,我们打印上面四个User类的编译信息

def tree1 = reify { class User1(var id: String, var name: String) }.tree
def tree2 = reify { class User2(val id: String, val name: String) }.tree
def tree3 = reify { class User3(private var id: String,private  var name: String) }.tree
def tree4 = reify { class User4(id: String, name: String) }.tree

然后分别打印上面的四个树,输出结果如下:

tree1:

{
  class User1 extends AnyRef {
    <paramaccessor> var id: Predef.String = _;
    <paramaccessor> var name: Predef.String = _;
    def <init>(id: Predef.String, name: Predef.String) = {
      super.<init>();
      ()
    }
  };
  ()
}

tree2:

{
  class User2 extends AnyRef {
    <paramaccessor> val id: Predef.String = _;
    <paramaccessor> val name: Predef.String = _;
    def <init>(id: Predef.String, name: Predef.String) = {
      super.<init>();
      ()
    }
  };
  ()
}

tree3:

{
  class User3 extends AnyRef {
    <paramaccessor> private var id: Predef.String = _;
    <paramaccessor> private var name: Predef.String = _;
    def <init>(id: Predef.String, name: Predef.String) = {
      super.<init>();
      ()
    }
  };
  ()
}

tree4:

{
  class User3 extends AnyRef {
    <paramaccessor> private[this] val id: Predef.String = _;
    <paramaccessor> private[this] val name: Predef.String = _;
    def <init>(id: Predef.String, name: Predef.String) = {
      super.<init>();
      ()
    }
  };
  ()
}
目录
相关文章
|
21天前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
1月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
43 3
|
1月前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
20天前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
141 68
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
19天前
|
运维 监控 持续交付
微服务架构解析:跨越传统架构的技术革命
微服务架构(Microservices Architecture)是一种软件架构风格,它将一个大型的单体应用拆分为多个小而独立的服务,每个服务都可以独立开发、部署和扩展。
149 36
微服务架构解析:跨越传统架构的技术革命
|
22天前
|
设计模式 负载均衡 监控
探索微服务架构下的API网关设计
在微服务的大潮中,API网关如同一座桥梁,连接着服务的提供者与消费者。本文将深入探讨API网关的核心功能、设计原则及实现策略,旨在为读者揭示如何构建一个高效、可靠的API网关。通过分析API网关在微服务架构中的作用和挑战,我们将了解到,一个优秀的API网关不仅要处理服务路由、负载均衡、认证授权等基础问题,还需考虑如何提升系统的可扩展性、安全性和可维护性。文章最后将提供实用的代码示例,帮助读者更好地理解和应用API网关的设计概念。
51 8
|
1月前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
54 1
服务架构的演进:从单体到微服务的探索之旅
|
27天前
|
消息中间件 运维 Kubernetes
后端架构演进:从单体到微服务####
本文将探讨后端架构的演变过程,重点分析从传统的单体架构向现代微服务架构的转变。通过实际案例和理论解析,揭示这一转变背后的技术驱动力、挑战及最佳实践。文章还将讨论在采用微服务架构时需考虑的关键因素,包括服务划分、通信机制、数据管理以及部署策略,旨在为读者提供一个全面的架构转型视角。 ####
35 1
|
29天前
|
弹性计算 运维 开发者
后端架构优化:微服务与容器化的协同进化
在现代软件开发中,后端架构的优化是提高系统性能和可维护性的关键。本文探讨了微服务架构与容器化技术如何相辅相成,共同推动后端系统的高效运行。通过分析两者的优势和挑战,我们提出了一系列最佳实践策略,旨在帮助开发者构建更加灵活、可扩展的后端服务。
|
29天前
|
消息中间件 运维 Cloud Native
云原生架构下的微服务优化策略####
本文深入探讨了云原生环境下微服务架构的优化路径,针对服务拆分、通信效率、资源管理及自动化运维等核心环节提出了具体的优化策略。通过案例分析与最佳实践分享,旨在为开发者提供一套系统性的解决方案,以应对日益复杂的业务需求和快速变化的技术挑战,助力企业在云端实现更高效、更稳定的服务部署与运营。 ####