老哥们都很幽默，不过据说人做梦是为了让自己适应环境，有意无意中会对自身做一些调节，从这一点上来看大自然塑造的生物机制真的很神奇，特别是人类。

这个需求可不简单了，毕竟涉及到的东西比较多，可能你需要透过容器调用 Docker 引擎的 API 来实现，这样做就跟你的部署配置耦合了，意味着你需要管理 Docker 的镜像以及容器。

Docker 引擎 API 文档： https://docs.docker.com/engine/api/v1.41/
可以使用 alpine/socat 这个容器将 Docker 的 unix socket 映射为一个可以请求的端口地址 ，加入到跟应用同一个 docker 网络中进行调用，这样你的服务就可以通过一个 HTTP 客户端来请求 Docker 引擎了。

你这个问题其实这个跟微服务没啥关系，跟容器也没有太大的关系，想想没有容器之前我们是怎么交付软件的？有了容器之后区别在哪里？

1 、当你发布的新的镜像，里面包含了最新的代码，那么客户升级的时候必然会拉取这个镜像并启动该镜像的容器。
2 、启动容器的时候，以前的容器如果同时运行，此时适当的切换流量至最新的容器内，如果没有问题，旧容器就可以停止了。
3 、如果不允许同时启动两个不同版本的容器，那么必然要停掉之前的，再启动新的（例如版本迁移，数据结构更改）。

所以这里没有什么神奇的地方，对于不兼容的升级，该停机还是得停机，否则迁移成本太高（你得同时维护新老版本的数据兼容、API 变更等等）。

我之前集成过 Activiti，本质上它就是一个有限状态机，使用它的目的就是为了应对频繁变更的审批流程。

既然是状态机，就涉及到状态节点的切换，即触发了什么事件（输入）导致状态进入到下一个状态（输出），每一个状态节点拥有生命周期，hook 节点生命周期的不同阶段用来处理自定义的逻辑，并且可以控制状态机的走向。节点有不同的类型，有些内置类型的节点，例如进入到这个节点就发送一封邮件，发送完以后进入到下一个节点。

对于我刚才说的以上这些功能，实际上就是一个流程的定义，这个定义不是通过我们写代码的方式来硬编码的，而是在运行时进行管理的，而这个定义也有一个标准（ bpmn ）用于规范整体的结构。

流程定义完成以后，下一步就是考虑如何将定义“实例化”，流程定义只是一个静态模板，它是元数据（即描述数据的数据），就像我们写一个 Java 类，是需要被实例化的。启动一个流程定义相当于创建了一个流程实例，每一个流程实例具有生命周期，从开始节点一步一步往下走，直到走到了结束节点。

Activiti 或者 Flowable （推荐）非常方便进行拓展，它完成了我们上面所说的那些基础功能（流程定义与部署、实例状态管理等等），我们可以自己按照需要进行定制化的开发。特别需要注意的就是，在使用上，不要把流程实例当做一个业务实体来用（例如你有 10W 个订单，但是里面未完成的订单也许只有几百个），每一个流程实例都有自己的生命周期，当它完成了以后，它的使命也就结束了，在 Activiti 中将会从 RU_XXX 系列表中移除，不过我们可以对其进行拓展，将它的结果存储到外部的一个归档数据库中。

对于简单一点的场景，例如所有的节点都是 UserTask （通常用于审批），可能自己设计一张表就结束了，压根用不到工作流引擎。但是对于以事件驱动的整个集成系统来说还是有意义的，特别是对于频繁变更的流程。

要真防的话是防止不了的，就如 2 楼所言，防君子不防小人，收集证据是一种方法，但是如果他们的服务器不联网或者屏蔽了你们的中央服务器，这一招就没有办法了。

以往的做法就是，软件根据所部署系统的一些特征生成一个唯一标识（ UID ），软件厂商根据一些算法，例如使用私匙对这个唯一标识进行签名生成一个授权码。客户获取授权码之后进行配置，然后软件启动的时候获取 UID，并根据授权码和公匙进行校验。

需要指出的是以上方法如果系统环境被复制（在系统层面没有什么是不能模拟的），或者软件内置的公匙被替换为他们自己的，都会导致此方法失效。

估计未来一段时间仍然会有这种独立部署的需求存在，除非客户端是断网的，内部使用的（例如学校内的一些系统），否则现在绝大多数服务基本上都转变为 SaaS 模式了，多租户使用一组服务器，数据上进行隔离分区，不仅方便版本升级，也省去了客户部署的操作。

可以拿多少工资看一下各类招聘信息就知道了，这一点取决于各种维度的信息，上下浮动空间也是比较大的，据我所知 Java 后端初学者目前在上海的话 8K 应该是可以拿到的，常用的框架要熟练，个人建议不要进那种 10 人以下开发团队的公司，在你这个阶段学东西上手才是主要的，能够学到什么经验很大程度上取决于公司目前所用的技术栈。

技术方面，Java 后端 Web 开发的话在国内几乎可以肯定会用到 Spring （ IOC 、AOP ），最常用的组合还是 SSM （ Spring 、Spring MVC 、MyBatis ），说白了就是最基础的 CRUD 。

另外就是关于数据库的知识，小公司一般后端开发还包括事务、表结构设计、查询优化等等，没有规模之前可能无需考虑拓展性，能够实现需求就行。

还有就是后端开发还涉及到安全（认证和授权）、统计（报表以及其他批量任务），总之如果需要你自己去设计和实现这些需求的话，那么需要了解的知识还有很多。

上了点规模的就要考虑到并发情况下如何拓展扩容、如何保证数据的一致性，能够分析系统的瓶颈在哪个方面，可以使用什么样的技术和架构来应对。不过到了这个阶段，公司应该早就已经规划好该怎么做了，等你工作了几年有了经验你自然会知道下一步该怎么走，需要学习什么样的知识。

题外话，我自己之前本身是做游戏客户端的，属于前端开发了，本身对编程语言是有一定的了解的，转后端（ 2017 年）对于我而言最大的障碍和枯燥点在于，后端涉及到的知识范围太广了，各种术语名词，导致我在一开始学的时候看一篇文章，里面每一个字我都认识，但是就是不知道作者在说什么，但是单独去查每一个概念和知识又会涉及到另外的一些概念，没有应用场景很难去理解一个概念到底是什么，有什么用。

但是，别以为我说了这么多就是为了吓唬你，我走到现在除了自己本身对这些东西感兴趣以外，最重要的一点就是：不要放弃！当你对各种概念了然于心的时候，你真的会感谢自己在之前无数个夜晚为此所付出的努力。

这一次回复字数应该比较多了，我也不继续废话了，如果楼主真的喜欢想要踏入这一个行业，那就干吧，多用 Google 、多读好书！

我也遇到过，没有越狱，起初还以为是存储满了，但实际上还有 100 多个 G，一般重启完就好了，大概每一个月会出现一次，也没搞懂到底是哪里出了问题。

一种方法论，DDD 的作者根据自己的经验提炼得出的一套通用建模方法，分为战术模式（ tactical patterns ）和战略模式（ strategic patterns ），其中战略模式是比较难以理解和抽象的，同时也是最重要。战术模式则可以归结为类似设计模式一样的方法工具。

难以理解就意味着用的人少，不好推广，可能一些团队的 leader 会强推或者应用其中的一部分，我想说的是放弃它是非常容易的，不对其进行维护就行了，但是重新拾取起来就会非常困难了。就像 TDD 一样，在思维没有转变过来之前，很多人就会认为它是浪费时间浪费成本的开发模式。

破窗效应所引发的一个结果就是，如果团队中有一个人可以打破规则，并且不受约束和惩罚，那么其他人也会尝试挑战规则，最终的结果就是混乱。

还区块链呢，这个链啥时候重写不还是他们控制的吗，没有可观测性的区块链有什么意义呢？

升级的时候不要插入任何外置 USB 设备，包括拓展坞，否则有可能出现问题。