Scala微服务架构 三

本文涉及的产品
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 四 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>();
      ()
    }
  };
  ()
}
目录
相关文章
|
3天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
6天前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
31 6
|
6天前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
19 1
|
12天前
|
弹性计算 Kubernetes Cloud Native
云原生架构下的微服务设计原则与实践####
本文深入探讨了在云原生环境中,微服务架构的设计原则、关键技术及实践案例。通过剖析传统单体架构面临的挑战,引出微服务作为解决方案的优势,并详细阐述了微服务设计的几大核心原则:单一职责、独立部署、弹性伸缩和服务自治。文章还介绍了容器化技术、Kubernetes等云原生工具如何助力微服务的高效实施,并通过一个实际项目案例,展示了从服务拆分到持续集成/持续部署(CI/CD)流程的完整实现路径,为读者提供了宝贵的实践经验和启发。 ####
|
2天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
11 1
服务架构的演进:从单体到微服务的探索之旅
|
1天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
14 5
|
3天前
|
监控 API 微服务
后端技术演进:从单体架构到微服务的转变
随着互联网应用的快速增长和用户需求的不断演化,传统单体架构已难以满足现代软件开发的需求。本文深入探讨了后端技术在面对复杂系统挑战时的演进路径,重点分析了从单体架构向微服务架构转变的过程、原因及优势。通过对比分析,揭示了微服务架构如何提高系统的可扩展性、灵活性和维护效率,同时指出了实施微服务时面临的挑战和最佳实践。
17 7
|
2天前
|
Kubernetes 负载均衡 Cloud Native
云原生架构下的微服务治理策略
随着云原生技术的不断成熟,微服务架构已成为现代应用开发的主流选择。本文探讨了在云原生环境下实施微服务治理的策略和方法,重点分析了服务发现、负载均衡、故障恢复和配置管理等关键技术点,以及如何利用Kubernetes等容器编排工具来优化微服务的部署和管理。文章旨在为开发者提供一套实用的微服务治理框架,帮助其在复杂的云环境中构建高效、可靠的分布式系统。
14 5
|
2天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####
|
5天前
|
消息中间件 供应链 架构师
微服务如何实现低耦合高内聚?架构师都在用的技巧!
本文介绍了微服务的拆分方法,重点讲解了“高内聚”和“低耦合”两个核心设计原则。高内聚强调每个微服务应专注于单一职责,减少代码修改范围,提高系统稳定性。低耦合则通过接口和消息队列实现服务间的解耦,确保各服务独立运作,提升系统的灵活性和可维护性。通过领域建模和事件通知机制,可以有效实现微服务的高效拆分和管理。
23 7