A

R

Spring Cloud Common Doc Index

https://docs.spring.io/spring-cloud-commons/docs/3.0.3/reference/html/index.html

Cloud Native is a style of application development that encourages easy adoption of best practices in the areas of continuous delivery and value-driven development. A related discipline is that of building 12-factor Applications, in which development practices are aligned with delivery and operations goals — for instance, by using declarative programming and management and monitoring. Spring Cloud facilitates these styles of development in a number of specific ways. The starting point is a set of features to which all components in a distributed system need easy access.

云原生是这样一种应用开发的风格：鼓励在持续集成和价值驱动开发领域采用简单地最佳实践。与之相关的discipline是构建 12-factor 应用，这是一种开发实践和分发及运营目标对齐的（方法论）——例如，通过使用生命式的编程、管理、监控。Spring Cloud以一组特定的方式来促进这种风格的开发。它的起点是一组在分布式系统中可以易于使用的功能组件。

  • 关于cloud native这个时髦词的一个opinion
  • 并且把cloud native和 12-factor扯在了一起
    • 实在搞不懂的是，spring cloud config等等玩意儿，和12 factor是同一种风格？也许人家说的是精髓，即便是这样我也真是不太明白
    • 同时对12-factor给出了一个更具体的opinion，其实我觉得也是牵强的，以我对12-factor的了解，这种视角有点拔高了，12-factor应该没有站在太多超出技术层面的价值观去定义太多东西
    • 但最让我觉得恶心的——确实spring cloud这东西从我最一开始了解有这么个东西的时候我就有点感觉恶心——是下一段他还提到了其与SpringBoot的价值观一脉相承？
  • 最后一句描述了spring cloud的基本形态…其实也没说过个鸟来

Many of those features are covered by Spring Boot, on which Spring Cloud builds. Some more features are delivered by Spring Cloud as two libraries: Spring Cloud Context and Spring Cloud Commons. Spring Cloud Context provides utilities and special services for the ApplicationContext of a Spring Cloud application (bootstrap context, encryption, refresh scope, and environment endpoints). Spring Cloud Commons is a set of abstractions and common classes used in different Spring Cloud implementations (such as Spring Cloud Netflix and Spring Cloud Consul).

以上特性很多也被Spring Boot所涵盖，Spring Cloud就是构建于其上。more特性（应该是指的Spring Boot所covered之外的）通过Spring Cloud的两个库提供（delivered）：Spring Cloud Context和Spring Cloud Commons。Spring Cloud Context为一个Spring Cloud应用的应用上下文（ApplicationContext）提供使用工具和特定的服务（包括：bootstrap上下文，encryption，refresh scope，和environment endpoints）。Spring Cloud Commons是一组抽象和公共的类被不同的Spring Cloud实现（如：Spring Cloud Netflix 和 Spring Cloud Consul）所使用

  • 第一句如前述虽然也不知道为啥，但是我确实感到恶心
  • 后面的很具体了，其实可以当一到面试题
    • 这两个东西其实一直是Spring Cloud的基石，但——我估计就是我而已——静不下心来看spring cloud的文档，所以一直也不是太关注到这个事情
    • 我也做了一件有点徒劳无功的事情，就是翻了一下我能看到的最早的spring cloud common的文档，大概是2.2.x版本（目前是303），而这里这几段在Spring Cloud Common这个project一开始就有
  • Spring Cloud Context包含的内容：
    • bootstrap context
    • encryption
    • refresh scope
    • environment endpoints
  • Spring Cloud Context的设计目标——为ApplicationContext提供支撑，而ApplicationContext是一个Spring Framework的概念
  • Spring Cloud Commons（就是这个文档所描述的主体？）是一组抽象、公共类
    • 具体是谁这里没说

If you get an exception due to “Illegal key size” and you use Sun’s JDK, you need to install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files. See the following links for more information:

Extract the files into the JDK/jre/lib/security folder for whichever version of JRE/JDK x64/x86 you use.

这块儿就不强翻了，都是一堆特定的名词，背后一堆乱七八糟的事情，可以参考这里，其实我也搞不太懂

Note：Spring Cloud is released under the non-restrictive Apache 2.0 license. If you would like to contribute to this section of the documentation or if you find an error, you can find the source code and issue trackers for the project at {docslink}[github].

这段就是打广告？让大家有人出人，有力出力，然后我也不知道是不是最后一点出了点bug？

以上就是Spring Cloud Common开篇的部分内容，结合整篇目录看下吧image.png

  • 应该chapter 1 就是对应Spring Cloud Context，就是包含bootstrap context和什么refresh scope的介绍，所以也难怪没有这个单独的Spring Cloud Context的文档link了

  • chapter 2 明显就是指 Spring Cloud Commons的抽象类部分，具体到3、4、5、6等等，不瞎猜了，当是带着问题往 后看：

    • LoadBalancer和Circuit Breaker是在Commons包里还是Context包里？
    • CachedRandomPropertySource是个什么鬼为啥值得单独列个chapter来说，他又在那个包里，怎么引进来？
    • Security又是啥？同样，那个包？怎么引
    • 到这也有个问题了，Spring Cloud Commons和Context这俩货的Maven座标是啥，能直接引么，还是通过别的组件都会引入这俩

  • chapter 7 讲述的内容也是挺明显的，不过也是猜，猜的主要是这些属性是不是意味着有了commons和context两个jar这些属性就都有的设了

    Spring Cloud Common Doc Index P -> A

  • 为前面我那些疑问的自答留个坑

    1.1. The Bootstrap Application Context

    https://docs.spring.io/spring-cloud-commons/docs/current/reference/html/#spring-cloud-context-application-context-services

1. Spring Cloud Context: Application Context Services

Spring Boot has an opinionated view of how to build an application with Spring. For instance, it has conventional locations for common configuration files and has endpoints for common management and monitoring tasks. Spring Cloud builds on top of that and adds a few features that many components in a system would use or occasionally need.

Spring Boot有一个如何使用Spring框架构建应用的鲜明的视角。例如，它约定了配置文件的位置并且设置好了common management和monitoring tasks的访问地址。Spring Cloud构建于其上，并且添加了一些特性，这些特性是系统中将要使用或者sometimes but not often 需要的不少组件

  • common management和monitoring tasks不知道是不是指的actuator
  • 后一句真不知道说的是个啥，就是没Spring Boot often的意思吧

1.1. The Bootstrap Application Context

A Spring Cloud application operates by creating a “bootstrap” context, which is a parent context for the main application. This context is responsible for loading configuration properties from the external sources and for decrypting properties in the local external configuration files. The two contexts share an Environment, which is the source of external properties for any Spring application. By default, bootstrap properties (not bootstrap.properties but properties that are loaded during the bootstrap phase) are added with high precedence, so they cannot be overridden by local configuration.

一个Spring Cloud 应用通过创建一个bootstrap context来运作，这个bootstrap context是主应用的parent context。这个context的职责是加载外部源的配置属性和解密本地外部配置的属性。两个context共享一个Environment，这个（environment？）是任何Spring应用外部属性的source？缺省情况下，bootstrap properties（不是指bootstrap.properties配置文件，但是那些在bootstrap 阶段加载的properties）以高优先级被添加，他们不能被本地配置复写

  • 这块儿算开始讲bootstrap.properties了吧，其实还真不是，下一段才讲的配置文件，这里讲的是bootstrap这个概念🤣
  • bootstrap context是 application context的parent context？
    • 每次看到这我都想重新翻一下Spring Framework的文档，按说应该给个引用
  • 区分了bootstrap properties和bootstrap.properties？玩儿文字有戏呢么

The bootstrap context uses a different convention for locating external configuration than the main application context. Instead of application.yml (or .properties), you can use bootstrap.yml, keeping the external configuration for bootstrap and main context nicely separate. The following listing shows an example:

bootstrap上下文这货为locating 外部配置采用了和主应用上下文不同的约定😂。取代了application.yml或properties扩展名，你可以使用bootstrap.yml文件，保持面向bootstrap的external 配置和主context nicely separate😅，下面是个例子

  • 感觉这段就是每个字都认得，和一起不知道说的是个啥，其实表面上应该就是区别于application.properties，剁了个bootstrap.properties，用来区分管理不同的内容？
  • 那上一段那个什么bootstrap properties不同于bootstrap.properties这个是怎么具体表达出来的？

Example 1. bootstrap.yml

  1. spring:
  2.   application:
  3.     name: foo
  4.   cloud:
  5.     config:
  6.       uri: ${SPRING_CONFIG_URI:http://localhost:8888}
  • 其实就是两个属性
  • 但下面三段神解释还是完全不知所云

If your application needs any application-specific configuration from the server, it is a good idea to set the spring.application.name (in bootstrap.yml or application.yml). For the property spring.application.name to be used as the application’s context ID, you must set it in bootstrap.[properties | yml].

就不翻了，其实挺直白的，但有问题：

  • 到底spring.application.name应该设置在哪儿？似乎都可以
    • 如果需要from server来确定application-specific的configuration，那么其实哪儿都一样
      • 那么什么叫from server呢？
    • 如果spring.application.name这个属性被作为applictions context ID来使用，则应该设定在bootstrap
    • 所以是不是区别就在于是spring.application.name
      • 作为applications context ID来使用
      • 还是from the server的一个application-specific configuration
      • 是不是应该再举个例子呢…

If you want to retrieve specific profile configuration, you should also set spring.profiles.active in bootstrap.[properties | yml]. 如果要取得特定profile的configuration，那么也应该在bootstrap.properties中设定spring.profiles.active

  • 这个算是明确，但为什么呢？

You can disable the bootstrap process completely by setting spring.cloud.bootstrap.enabled=false (for example, in system properties).

也可以通过设定spring.cloud.bootrap.enabled=false来完全禁用bootstrap过程（例如，在 system properties）

  • 其实括弧没看懂
  • 禁用了有啥损失吗？


T

image.png

  • 好用
  • 功能键全按+U
  • 看源码的利器应该，然后同时发现自己的代码是多模的没有继承体系
    • 未必是坏事🤣

S

为啥觉得iBizEAM和slassets这俩货都很烂呢

背景

  • 工作需要
  • 做一个资产管理的产品选型，兄弟公司可能要在这个基础上做自己的资产管理产品

  • 就是搭建，跑起来，上面给的选型是iBizEAM和slassets

    郁闷的背景

  • slassets没跑起来，卡在一堆配置不知道在哪儿🤣，而且发现就没个页面，也等同于几乎没有文档

  • iBizEAM可以从代码跑起来，但是执行过程中觉得缺东西，明明文档里面写的是已经禁用了nacos注册了，但配置里面还强依赖这么一个名字

  • iBizEAM也可以从一个docker-compose编排文件跑起来，但是从提交时间看，这组image已经落后于其代码仓库了

    • 而且iBizEAM工程里面没有文档指出有这种run的方式，完全是用我自己的狗眼寻摸出来的

      郁闷的对比

  • ODoo不说了，虽然没有试，不过看起来整个社区发展的确实更好

    • iBizEAM也说了就是向其学习的

  • 有另一个欧洲朋友做的有开源社区版的ERP，https://www.axelor.com/

    • 这个跑起来了，docker一键，让人想起来gitlab的docker启动，丝般顺化

      疑惑

  • 外国的月亮为啥就真的看着更圆呢？

    分析

  • 产品本身耕耘多年，都比这俩国产有历史

  • 国内起步的基础可能不适合

    • 其实都是spring cloud和spring boot 就缺少基本的正确的理解
      • slassets稍微好点，是一个更扁平化的maven多模块工程
      • iBizEAM把maven多模块工程层级搞得非常之深，完全不同于spring boot 的optinionated view，再搞进spring cloud这个on top of spring boot的东西，把自己呈现出来的实施架构（或者叫部署架构）搞得异常复杂
      • 不是说这么搞不行，好歹文档写清楚（因为已经严重不遵循spring boot的convention），但是这也没有做到
    • 根源上可能是对微服务架构风格缺少基本的理解
      • axelor和gitlab，其实也都是SOA的架构，比较理性的就没有搞注册中心这种东西
      • 过分追求一些幻象中的独立执行特性，这个iBizEAM的工程结构上有这个端倪，但是没有完全去印证这个事情，毕竟没这个时间去浪费生命，其实微服务架构风格语境下，说的是没个服务独立的变更，不是说还要拆开独立跑得意思
    • 云原生大背景下，对单机容器编排和集群容器编排的准备都不够
      • 这是我个人最遗憾的一点，其实从cloud native大势上看，其实应该认为spring cloud出局了才对，不知道为啥大家都这么热衷，一个可能的分析就是…k8s、容器相关的东西太ops化了，而国内除了大厂的个别局部，都没有认识到这种趋势，各个职能角色的惯性认知还是非常陈旧，运维、测试角色还不被认为是比单纯coding更综合更高级的工种，开发自己不懂测试、运维技能又自认在鄙视链顶端，结果故步自封不停的搞spring cloud 和 dubbo这种东西
      • iBizEAM的docker-compose编排其实很好，就是缺文档
      • axelor也是单容器多进程玩儿法，和gitlab是一样的，这个风格其实玩儿的也很适合这种产品推广起步的
      • 集群容器编排的一般都是社区维护这个倒是不必苛求，但是通过这类文件描述出对外部资源的需求和相互关系，恰恰是集群容器编排的另一个重要的作用

        结论

  • 国货开源无论如何都值得尊敬，但

  • 眼界还要放开，从更大尺度上去学习业界先进的架构风格、设计细节、工程推进能力和产品推广等全方位的经验和实践方法