https://hexed.it

这个还不错，直接浏览器打开就行了

我理解的你这个 APP 的激活是不是类似于签发密钥然后激活的单机授权模式，也就是用户在没有联网的情况下也能正常付费激活，比如私钥签名，然后 APP 校验，没问题的话就读取里面的授权信息，激活就算成功了？

如果破解者能够把你的授权部分修改掉，伪造出授权成功的信息通过校验，那么你的 APP 就会认为这确实是已经付费的正常用户。除此之外你在没有授权时做的任何校验都失去了存在的意义。

因此在你做各种校验之前，最好先考虑一下哪一部分才是最关键的。

加固就行了，除非是特别特别需要防止别人破解的 APP ，这个时候才应该考虑在源代码级别上面进行特殊的逻辑处理，另外也可以花钱买专业的加固工具，权衡利弊选择适合的就可以啦。操作系统都能被破解，iOS 都能被越狱，更别说 APP 了。抱着学习的态度去尝试了解这一行也是有价值收获的。

不太懂这一块，国外的劳务合同应该走国外的劳动政策吧，对应过来在国内是什么存在呢？感觉有点像是外包私活性质了，有点好奇这种私对私转账会不会引起注意？个税申报也是在汇算清缴的时候自己填上去？

这个不是单元测试吧，这个算是集成测试了，需要在独立的测试进程中对其进行测试，就好像是应用程序的真实使用者一样。

对于单元测试，如果测试的目标依赖了一个外部的组件，常用的做法是对这种外部组件进行 Mock ，比如测试目标需要一个发送消息的服务（ MessagePublisher ），可以 Mock 一个消息发送服务（ InMemoryMessagePublisher ），然后对测试目标进行测试，并观察 InMemoryMessagePublisher 中的结果是否符合预期，当然这只是一个很简单的例子，因为单元测试足够小，所以可以反复快速的完成测试内容。

测试是一个很复杂的概念，每个人或者组织都有不同的偏好，在我看来归根结底无非就是两个问题，那就是搞清楚我们到底在测试什么？我们期望测试将来可以起到什么帮助？

@bk201 我用的是添可的洗地机（芙万 2.0 ），型号差异感觉并不是很大，主要是清理方便。

Ioc 的主要作用就是读取组件声明（ XML/注解 /代码注册），也就是构造 IoC ，然后实例化和管理这些组件的生命周期。
根据构造组件所需要的定义（面向对象语言中通常是 class 的构造函数），就可以得到创建这些组件所需要的先后顺序，从而不必手动去硬编码这个过程。
另外 IoC 本身的生命周期（创建 /销毁）形成了一个 scope 作用域，从而可以管理存在于容器内的各种实例。
所以一般 IoC 有两个阶段，一个阶段是读取声明（注册组件，构造 IoC ），另一个阶段是构造和管理组件。

对于非面向对象的语言，我能想到的就是在读取组件定义这一块（即对应面向对象中 class 的构造函数），转变为了一个 Key 和包含回调函数的 struct 。
这个 key 可能就是一个简单的字符串，类似 map 或者 dict 中的 Key 。
这个 struct 由 IoC 定义，里面包含了初始化定义（依赖描述），生命周期回调函数（函数签名由 IoC 定义），以及一个指向实际值的 interface{}指针。
上面说到 IoC 本身也是有生命周期的，它提供了一种作用域的语义，因此可以很方便的管理一系列组件的实例。

另外说一下 SpringBoot 的各种 starter 也只是提供了一个默认的组装布局，或者称之为开箱即用的默认配置，只不过可以根据配置文件来自动进行组装逻辑，这就需要提供一种通用的描述规范。

洗地机很好用，我是一点容不得地上有什么污渍的，比如有一根毛发也要用纸把他给清理掉，可能是有点强迫症，甚至在吃饭的时候会时不时扭头绕着身子观察地面上有没有什么东西，这个毛病怎么也改不了。

没明白你说的对用户不友好是啥意思，往一个已经删除的关联数据增加新的数据，按理说应该失败并告知原因，例如不存在 menu ，除此之外还能怎么做呢？可以吞掉这个错误，就当请求没发生，或者正常插入脏数据？

数据已被删除是一个事实，优化的方案也可以当有用户编辑 menu 的时候不允许删除，这取决于想要的逻辑是什么。

回到正题，解决这个并发问题最简单的方法就是使用乐观锁，或者直接使用独占锁（ SELECT ... FOR UPDATE ）。如果是独占锁，当你在进行操作的时候（新增 content ），别人是没办法查询或者修改这个 menu 的。当完成操作，另一个试图删除 menu 的时候，走正常的删除逻辑。

我家里的 K2P 一样的，桥接拨号刚开始可以达到 50MB 的下载速度（ 500M 宽带），过一段时间以后就基本上 20MB 左右（ 5G ），之前查过好像要刷系统开启什么功能，不过我一年很少在家，也懒得去搞了，下次回去准备把路由器换了。

y5ufWZiEhGM 谢谢

给微服务一个定义吧，普遍认为的微服务就是把什么订单、用户等等系统拆分出来当作一个独立的项目来开发和部署，但是需要注意这个“拆分”只是逻辑上的。

比如我在开发的时候将所有的服务都放在一个项目里面，然后最终只打包出一个可执行文件来，分别在 ABC 机器上面进行部署，然后在 nginx 上面针对请求的 URL 路径转发到不同的机器上。我可以在 ABC 机器上面都分别配置不同数据库，毕竟这台机器只负责部分子集，只会操作部分的数据表，这样一来出现的一个问题就是 ABC 之间数据不互通了，比如订单需要查询用户信息，调用 UserService ，UserService 将不会查询到用户数据，因为这些数据存在于另一台机器和另一个数据库上，一种办法是 ABC 三台机器使用同一个数据库，这样可以解决数据互通的问题。注意自始至终我没有使用到 RPC 以及消息队列，我只是将同一个程序部署到了三台机器上，每一个机器负责部分的 URL 请求，你说这算不算是微服务呢？

如果你认为不算，我们可以改造一下，当某一个机器调用 XXXService.doSomething()的时候，实现不再是通过 JVM 进程内直接调用对象方法，而是通过构造 HTTP 请求另外一台专门负责这服务的机器来进行处理，这样一来，我们就可以将 ABC 三台机器又恢复到使用各自独立的数据库。如果我们拆分得足够好，三台机器应该至始至终只会生产和查询自己负责的那几张表。你说这算不算是一种微服务呢？

注意不管我如何部署，我们的开发结构仍然是一个单体的大项目，所有的代码在变更以后都需要重新打包然后部署到三台机器上面，但是如果我只修改了 A 机器负责的功能，我可以只更新 A 机器那一份，只要接口没有变动，其他两台机器仍然可以正常请求。

既然 ABC 都只负责部分功能，那为什么不在开发的时候就建立 3 个项目呢？这样岂不是更加清晰吗？的确可以这么做，但是我想说的是这样并不是必须的，或者说这不是重点，那么重点是什么？重点就是你如何确定这是 3 个项目而不是 4 个或者 5 个呢？是根据有 3 台机器我们就得有 3 个项目吗？所以重点就是如何找到进行拆分背后所隐含的那些逻辑，这些逻辑就是你的业务组织方式。

早前，我以为开发微服务就是把各种 Service 拆分出来当作一个独立的进程，使用独立的数据库，然后通过 RPC 进行相互调用，成功的把的注意力集中到了各种注册中心，网关，配置中心等等令人眼花缭乱的东西上面去了。在经历各种各样的填坑之后，回过头来再想一下，如果我只是作为一名开发，真的有必要去了解这些东西吗？我把大量的时间浪费在了去研究这些鬼东西上，反而把应该排在第一位的需求给丢到了一边。当服务网格和容器化出现以后，我对微服务这个词有了一些不一样的定义，说到底微服务终究不过是一种部署策略，它不是什么开发架构，它只是一系列指导如何正确开发服务的约定和理念，有了这些理念，我们就可以更容易的开发出适配部署运维的应用服务。微服务的终极目标，不是教我们如何用什么开发框架，用什么中间件，而是为了实现如何使资源利用得更加合理，更加有弹性，更加可伸缩。

夏新 F9 ，6.2 元包邮，2000 毫安电仓，耳机电量连续使用 5 小时。

@MIND222 巧了，今天刚看到一个帖子还是在讲这个的，不过我也不确定正不正确，https://bbs.hupu.com/53369394.html

每天撸一管算不算是一种运动呢，排泄一下应该还是挺有用处的，雄性激素过旺导致我头发溢脂性脱发了，发际线快要变成 M 形状了。

我之前买了一个背包，结果用了一个月之后拉链坏掉了，觉得扔掉之后很可惜，然后我在网上买了十几米的拉链（几块钱包邮），自己一针一线的给换了，除了边角不好缝，其他的还好。花了 3 天时间缝完了，现在使用良好。

事务是基于链接的，也就是说一旦你开启了一个事务，并且希望接下来的调用使用同一个事务，那么就必须使用同一个链接，就必须要把这个链接保存到一个地方，让所有使用数据库的方法都能够以一种相同的方式获取一个链接。

在 Java 中可以使用 ThreadLocal 来保存线程安全的变量，在当前线程的执行过程中，获取到同一个链接实例。如果是异步的，那就必须要考虑到链接的创建与提交，也就是要明确在什么时候开始，什么时候结束，Spring 的注解实现基于 AOP 的拦截，在“同步方法”调用之前开启事务，调用之后结束事务，它在背后实现了我上面第一段说的那些内容。

所以在没有 ThreadLocal 可以使用的时候，你必须要将一个链接进行传递，比如将链接封装到一个 Context 结构中，设计出一套接口标准，让所有使用数据库的代码都遵循这一套接口。不仅如此，还需要考虑到“同步”与“异步”的使用同一个链接将会带来怎样的影响，因为协程本质上也是在一个线程上运行，当多个协程同时运行在不同的线程时，就需要考虑到并发问题，因此不太建议“异步”使用一个事务。我对 Go 不太熟悉，但是背后的逻辑应该是以上这些内容。

看情况

如果大多数情况令牌都足够充裕，第二种实际上是更好的做法，因为直接写了，相比第一种，少了一个读的操作。
如果大多数情况下令牌不够充裕，那么第二种相比第一种多了一个写的操作。

但是很显然，我们大概率无法提前得知哪种情况才是相对常见的，我个人的话会选择第一种。