https://mp.weixin.qq.com/s/G9re_-Cyx2-U4f35csS0Yw

问题描述 单机下部署多个docker-compose, 并用nginx proxy manager 反代其他docker compose的流量，出现连不上其他docker compose 下的container的问题 尝试过的解决方式 1、地址用docker0的地址，端口用其他container暴露出来的端口，不行 2、换机器，不行 3、换docker、docker-compose 版本，不行 最终的解决方式 手动将多个docker compose加入到同一个docker network. 具体参考: 1、https://nginxproxymanager.com/advanced-config 2、https://stackoverflow.com/questions/38088279/communication-between-multiple-docker-compose-projects 3、https://github.com/NginxProxyManager/nginx-proxy-manager/issues/555 05.20 更新 最终还是要解决容器内无法访问宿主机IP的问题，非常诡异： 1、容器内可以ping通其他容器的hostname, 端口也是通的 2、容器内可以ping通宿主机ip (eth0) 3、但是容器无法连上宿主机的端口 4、公网可以正常访问宿主机的服务(端口是通的) 排查一圈发现是防火墙的原因，Ubuntu 22.04 TLS, 记得要把防火墙关了！(ufw disable) 艹！ 参考过的几个有用文章： 1、https://juejin.cn/post/7180619106407120933 2、https://gist.github.com/bruno-brant/e119da3713a657036ff7e3446d98176a 一般软件打的镜像都比较轻量，用的alpine版的linux比较多，进容器后用apk update && apk add… 装一些常用软件，方便排查问题。

MySQL InnoDB 行记录格式（ROW_FORMAT） 一、行记录格式的分类和介绍 在早期的InnoDB版本中，由于文件格式只有一种，因此不需要为此文件格式命名。随着InnoDB引擎的发展，开发出了不兼容早期版本的新文件格式，用于支持新的功能。为了在升级和降级情况下帮助管理系统的兼容性，以及运行不同的MySQL版本，InnoDB开始使用命名的文件格式。 1. Antelope: 先前未命名的，原始的InnoDB文件格式。它支持两种行格式：COMPACT 和 REDUNDANT。MySQL5.6的默认文件格式。可以与早期的版本保持最大的兼容性。不支持 Barracuda 文件格式。 2. Barracuda: 新的文件格式。它支持InnoDB的所有行格式，包括新的行格式：COMPRESSED 和 DYNAMIC。与这两个新的行格式相关的功能包括：InnoDB表的压缩，长列数据的页外存储和索引建前缀最大长度为3072字节。 在 msyql 5.7.9 及以后版本，默认行格式由innodb_default_row_format变量决定，它的默认值是DYNAMIC，也可以在 create table 的时候指定ROW_FORMAT=DYNAMIC。用户可以通过命令 SHOW TABLE STATUS LIKE'table_name' 来查看当前表使用的行格式，其中 row_format 列表示当前所使用的行记录结构类型。 PS：如果要修改现有表的行模式为compressed或dynamic，必须先将文件格式设置成Barracuda：set global innodb_file_format=Barracuda;，再用ALTER TABLE tablename ROW_FORMAT=COMPRESSED;去修改才能生效。 mysql> show variables like "innodb_file_format"; +--------------------+-----------+ | Variable_name | Value | +--------------------+-----------+ | innodb_file_format | Barracuda | +--------------------+-----------+ 1 row in set (0.00 sec) mysql> show table status like "test%"\G *************************** 1. row *************************** Name: test Engine: MyISAM Version: 10 Row_format: Dynamic Rows: 4 Avg_row_length: 20 Data_length: 80 Max_data_length: 281474976710655 Index_length: 1024 Data_free: 0 Auto_increment: NULL Create_time: 2018-08-07 13:07:59 Update_time: 2018-08-07 13:08:01 Check_time: NULL Collation: utf8_general_ci Checksum: NULL Create_options: row_format=DYNAMIC Comment: 二、InnoDB行存储...

If you have ever worked with MySQL, you inevitably came across character sets and collations. In this blog post, we will try to give you a more in-depth look at what those two are and how you should use them. What Are Character Sets and Collations? Simply put, character sets in MySQL are sets of symbols and encodings – collations are sets of rules for comparing characters in a character set....

初步再来探讨下架构设计和概要设计的区别和边界问题。先谈下架构设计： 架构设计包括了功能性架构和技术架构设计两个部分的内容，功能性架构解决业务流程和功能问题，而技术架构解决非功能性需求等问题。两种架构都包括了动态和静态两个方面的内容，对于功能性架构中动态部分为业务流程驱动全局用例，用例驱动的用例实现等；对于技术架构中动态部分为架构运行机制，而静态部分为框架，分层等方面的内容。 功能性架构包括了全局用例设计，这个本身是用例分析和设计的一个延续，而全局用例分析建议的思路仍然是业务流程，业务用例建模到系统用例建模的过程。全局用例分析清楚后可以开始考虑子系统和模块的划分，形成系统的功能架构图，当然在划分过程中一定要考虑到通过CRUD矩阵等分析方法来分析模块如何划分合理，如何保证模块本身高内聚和松耦合。 在全局用例分析完成后涉及到数据模型的设计，数据建模仍然从业务驱动，从最初的业务对象和单据入手，到最终的数据概念模型和逻辑模型等。架构设计中全局数据模型不一定覆盖所有的数据对象和数据表；但是核心的主数据，核心业务单据数据一定要覆盖到，模型到的层次到逻辑模型即可。如果用面向对象的分析方法，这里需要出的是UML建模中的概念模型和逻辑模型，体现核心对象和类，核心对象和类之间的关系。 将全局用例分析和数据模型建立融合在一起，可以看到这两者结合起来会形成一个系统完成的领域模型层。一直认为领域模型思路应该引入架构设计，只有领域模型才是真正关注功能性架构，而不用马上关注到具体的技术分层和技术实现。 前面两者做完后可以看到一个大系统被分解为了多个子系统或模块，那么接着要考虑的就是模块间的集成架构，分析完集成架构模块间的接口基本就出来了。接口设计应该是架构设计的另外一个核心内容。要明白架构设计一个重要作用就是架构设计完成后各个模块可以并行开始概要设计，详细设计和开发工作。只要大家都遵循架构设计约定的接口规则即可以了。 集成架构考虑完另外一个核心内容就是公共可复用组件的抽取和识别，包括了功能组件和技术组件，需要识别出来哪些是可复用的，如何进行复用。对于复用层次本身又包括了数据层复用，逻辑层组件复用，界面层UI组件的复用等。复用是架构价值体现的的另外一个关键点。 这些都做完后，接着一个步骤应该在架构设计阶段做的就是对架构输出成功进行模拟验证，前面完成了分解动作，必须通过模拟验证来看看后续分解内容能否很好的集成和组装。很多时候我们做架构设计的时候往往不做这块内容，导致架构设计一些内容变成空中楼阁，无法落地。 再回来看技术架构设计，首先谈下静态部分的内容。这里面就包括了软件开发的分层架构，开发框架等内容，包括开发规范约定，技术平台和语言的选择，使用的规约等都需要考虑。很多时候我们看到谈架构的时候说到的三层或多层架构，仅仅是完整架构设计里面很小的一部分内容。 除了分层架构外，接着考虑的就是各种非功能性需要，我们在架构上需要如何设计。这里面包括了事务，缓存，异常，日志，安全，性能，可用性，容错能力等。这些逐个点都要在架构设计中说清楚如何考虑，由于这些本身就属于一个应用系统中技术平台要考虑的内容，因此应该设计为较为公用的技术组件供上层的业务组件使用。要明白很多时候为何谈到AOP或可插拔架构，只有这样去考虑问题，才会考虑真正的功能性架构设计和功能实现和非功能性技术架构这块充分解耦，实现进一步的灵活装配。 再回到架构设计视图层面，还需要考虑的就是整个应用系统的部署架构，部署架构本身也包括了逻辑视图和物理视图，应用最终开发出来了如何进行部署，这涉及到了IT基础架构方面的细化，也需要考虑清楚。 概要设计 概要设计首先要明白的是根据架构设计的内容进一步对某个模块的设计进一步细化。架构设计在系统级，而概要设计在子系统或模块级。拿建筑来比喻，架构设计是把一个建筑的框架结构全部定清楚，包括地基要挖多深，核心框架和承重结构如何，每一层的结构图如何，应该分为几个大套间这些内容都应该定下来。每个大套间的水，电，气等管道接入点在哪里等。而概要设计要做的是拿着一个套间，来考虑这个套间内部该如何设计，如何划分功能区域，如何将水电气接入点进一步在房间内延伸，哪些地方需要进一步增加非承重的隔断等。 基于以上思路我们看到在架构设计的时候，除了很少部分的核心用例我们会谈到具体的用例实现完，大多数功能我们都不会谈到具体的用例实现层面。而到了概要设计则需要进一步的分解我这块模块究竟需要实现哪些功能点，具体的每个功能点究竟如何实现都必须要考虑到。 严格的概要设计，我们希望是到了概要设计的某个功能模块，模块所涉及到的核心的类全部会出来，类关系图全部会出来。数据库设计也进一步细化到该模块的数据库物理模型。对于用例进行用例实现分析，在实现分析过程中可以看到每个类核心的public方法全部会分析识别出来。 拿着架构设计的接口，概要设计也需要进一步细化，细化出接口具体的输入输出和使用方法，包括模块应该使用哪些外部接口，模块本身又提供哪些接口出去都必须细化清楚。做概要设计的时候一定要清楚当前做的这个模块在整个应用系统架构中的位置，和外部的集成和交互点。 概要设计不用到详细设计这么细化，包括类里面的私有方法，public方法的具体实现步骤和逻辑，伪代码等。但是我们要看到概要设计里面对于核心的业务逻辑必须要设计清楚如何实现，实现的机制和方法。很多时候我们到了概要设计画uml的时序图，很多时候一看没有任何意义，全是跨层的简单的交互和调用。这个应该在架构设计的架构运行机制说清楚即可。设计到多个业务类间的交互调用才是重点，一个简单的功能增删改查，完全没有必要画什么时序图。 其次架构设计中给出了各种安全，性能，缓存的设计。那么在概要设计中出来另外一个问题，即架构给出的各种实现方案和技术，我们在概要设计中如何选择，如何使用。不是所有功能都需要缓存，那就要说清楚哪些功能根据分析需要缓存，需要缓存哪些对象，缓存本身的时效性如何设置等问题。 概要设计作为我们要达到一个目的，就是不论是谁拿走概要设计来做，最终实现出来的功能模块不会走样，功能模块最终实现出来可能有性能，易用性等方面的问题，但是整个功能实现的大框架一定是定了的。 另外一篇文章可参考：http://321echo.blog.163.com/blog/static/999257872010020102113705/ 转载自博客园