ARTS 打卡第三周
1、A 算法题
题目:
给你一个字符串数组,请你将 字母异位词 组合在一起。可以按任意顺序返回结果列表。
字母异位词 是由重新排列源单词的所有字母得到的一个新单词。
示例 :
解题:
主要是 dict.get()函数的理解 dict.get(key, default=None)
1. key -- 字典中要查找的键。 2. default -- 如果指定键的值不存在时,返回该默认值。
2、R 阅读英文文章
英文原文:How to Structure Your Machine Learning Team for Success
本文讨论了可供选择的机器学习团队组织模型,并提出了将团队结构与公司发展阶段相匹配的建议。
集中式模式:集中式模型中的角色结构便于快速迭代和专业知识开发。
联邦模型:跨部门,专业团队在联合模型(有时称为混合模型)中进行协作。
嵌入式模型:需要在跨职能团队之间分配机器学习专业知识。
探讨一下这三种模式如何与公司的成熟度及其带来的好处相一致。
1、早期公司:集中模式通常有利于初创企业和处于起步阶段的公司。优点:
凭借专注的专业知识快速开发模型。
机器学习知识的坚实基础。
明确机器倡议的责任。
2、中型公司:随着公司规模的扩大,联合模型可以帮助管理日益增长的复杂性。优点:
特定领域的专业知识。
跨部门协作。
中央监督和专门单位之间的平衡控制。
3、大型企业:拥有机器实践的成熟公司可以通过嵌入式模型蓬勃发展。优点:
无缝集成的机器学习解决方案。
针对不同功能定制机器学习应用程序。
通过持续合作实现快速创新。
模型之间的转换。
思考
有效利用机器学习技术促进业务增长需要有效的团队组织。一个公司的成熟度和成长轨迹应该影响团队结构的选择。初创企业可以使用集中式模型快速迭代,中型公司可以使用联合模型进行协作,大型企业可以使用嵌入式模型将机器学习无缝集成到其运营中。
公司可以通过认识到机器学习团队不断发展的需求并相应地调整团队结构,充分利用机器学习的潜力来推动创新和成功。
3、T 学习技术技巧
MegaCli Raid 工具使用与磁盘分区格式化(适用于 DELLR740、R750 机器的 RAID 卡)
1、安装
rpm -ivh MegaCli-8.07.14-1.noarch.rpm
2、配置 Raid
查看磁盘情况:
/opt/MegaRAID/MegaCli/MegaCli64 -LdPdInfo -aALL | egrep "Ada|Vir|Slo"
Adapter #0 #Raid 卡序号 0
Number of Virtual Disks: 3 #分区个数,对应 lsblk 的 sda、sdb、sdc
Virtual Drive: 0 (Target Id: 0) #分区序号 0,对应 sda
Slot Number: 0 #分区 0 包含的磁盘插槽序号 0
Slot Number: 1 #分区 0 包含的磁盘插槽序号 1
Virtual Drive: 1 (Target Id: 1) #对应 sdb
Slot Number: 2
Virtual Drive: 2 (Target Id: 2) #对应 sdc
Slot Number: 4
Slot Number: 5
Slot Number: 6
Slot Number: 7
Slot Number: 8
Slot Number: 9
Slot Number: 10
Slot Number: 11
Adapter #1 #Raid 卡序号 1
Number of Virtual Disks: 0 #没创建分区
3、删除磁盘分区步骤(举例删除 sdb)
/opt/MegaRAID/MegaCli/MegaCli64 -cfglddel -L1 -a0
-L1 -a0 :即删除 Raid 卡序号 0 中分区序号 1 的分区,对应 sdb,删除后会释放占用的磁盘,对应 Slot 2 ,Slot3。
Adapter #0
Virtual Drive: 1 (Target Id: 1)
Slot Number: 2
Slot Number: 3
4、查看 Raid 卡适配器个数:
/opt/MegaRAID/MegaCli/MegaCli64 -adpCount
Controller Count: 1. #只有一个 Radi 卡
Exit Code: 0x01
5、查看 DeviceID 和 SlotNum
/opt/MegaRAID/MegaCli/MegaCli64 -PDList -aALL | egrep 'Enclosure Device ID|Slot Number'
Enclosure Device ID: 32 #ID 号,同一个 Raid 卡,ID 号相同
Slot Number: 0 #硬盘插槽序号
Enclosure Device ID: 32
Slot Number: 1
Enclosure Device ID: 32
Slot Number: 2
Enclosure Device ID: 32
Slot Number: 3
Enclosure Device ID: 32
Slot Number: 4
Enclosure Device ID: 32
Slot Number: 5
Enclosure Device ID: 32
Slot Number: 6
Enclosure Device ID: 32
Slot Number: 7
Enclosure Device ID: 32
Slot Number: 8
Enclosure Device ID: 32
Slot Number: 9
Enclosure Device ID: 32
Slot Number: 10
Enclosure Device ID: 32
Slot Number: 111
6、将分区 sdb 和 sdc 合并成一个分区,并做 Raid5
停用 sdb、sdc 的进程。卸载分区:
umount /dev/sdb
umount /dev/sdc
删除 sdb 分区,对应 L1 a0:
/opt/MegaRAID/MegaCli/MegaCli64 -cfglddel -L1-a0
删除 sdc 分区,对应 L2 a0:
/opt/MegaRAID/MegaCli/MegaCli64 -cfglddel -L2 -a0
此时 SlotMun 2 - 11 空闲,2-10 做新的分区,11 用于 Raid5 的备份盘:
/opt/MegaRAID/MegaCli/MegaCli64 -CfgLdAdd -r5 [32:2,32:3,32:4,32:5,32:6,32:7,32:8,32:9,32:10] CachedBadBBU Direct -a0
#32 为 Raid 卡 Device ID 号,2,3...为 Slot 编号对应磁盘
创建热备盘
/opt/MegaRAID/MegaCli/MegaCli64 -pdhsp -set -physdrv[32:11] -a0
7、格式化分区
格式化需要等待较长时间
mkfs.ext4 -D -E lazy_itable_init=0,lazy_journal_init=0,stripe_width=512 -O extents,dir_index,flex_bg,bigalloc /dev/sdb
对/sdc 分区整体格式化
mkfs.ext4 -D -E lazy_itable_init=0,lazy_journal_init=0,stripe_width=1920 -O extents,dir_index,flex_bg,bigalloc /dev/sdc
8、将分区改成 GPT 格式
fdisk /dev/sdc
: g #改成GPT格式
: w #保存并退出
9、挂载分区
vim /etc/fstab
10、创建 Raid1
/opt/MegaRAID/MegaCli/MegaCli64 -CfgLdAdd –r1 [32:3,32:4] CachedBadBBU Direct -a0
4、S 分享技术文章
服务拆分是微服务改造的第一步,也是最为关键的一步,拆分是否合理,决定了整个微服务化过程的成败,因此,需要有科学的拆分原则和拆分方法,保证拆分过程有序进行。
4.1、拆分原则
微服务拆分前,需要确定拆分的基本原则,微服务拆分的一个非常重要原则是无状态,无状态服务方便扩展和运维,所以无状态设计需要贯穿到微服务架构设计的全局层面进行思考。
服务拆分粒度并不是越细越好,需要结合当前团队的人员情况而定,比如当前团队只有 5 个人,如果拆分后的微服务个数超过 50,和人员的数量严重不匹配,不仅不会带来效率的提升,反而会导致效率的下降,建议拆分后每个人维护的微服务不要超过 3 个,并且每个微服务都有相应的备用负责人,规避可能的突发风险;针对多团队异地开发的情况,最好拆分后每个子团队负责的微服务相对独立,尽量减少异地团队的直接沟通成本。
微服务拆分时经常会遇到一些问题,比如是否需要拆分、拆分粒度的问题等,一般原则是遇到痛点问题时才进行拆分,非拆分不可时才启动微服务拆分,不要为了拆分而拆分。对于拆分方案拿捏不准的场景,尽量先不进行拆分,等想清楚了再定,避免拆分不合理,带来大量返工。
拆分后的微服务组织上层次不要过深,一个请求的处理过程中经过的微服务个数不要超过 5 个,链路太深会导致定位和追查问题特别麻烦,同时也会带来一定的性能损耗。对于拆分后的子服务来说,尽量避免相互依赖的场景,子服务调用时相互依赖会导致升级和维护时特别麻烦,增加很多不必要的运维成本。
4.2、拆分方法
微服务拆分的总体思想是根据高耦合、低内聚的原则识别出各个微服务的边界。具体拆分思路和业务形态紧密相关,没有绝对的标准。
以数据为维度进行拆分
按照数据拆分,是微服务拆分中最常见的一种方式,没有特殊考虑时一般根据领域实体数据进行拆分,拆分出来的服务负责处理给定的数据/资源的所有操作。以电商系统为例,大体可分为订单系统、用户系统、库存系统等。以订单系统为例,订单系统就负责订单核心数据的维护、订单数据的增删查改,确立了主要实体数据后可以根据数据的查询、修改等确定服务的接口,如订单的各种查询接口以及订单状态更新接口。根据数据维度把系统可以拆分出若干个子服务,但这些数据之间会有不少关联关系。
按照使用场景拆分服务
这种拆分方式也比较常见,如顺风车的所有后端查询操作之前都在一个单体服务里面,有固定路线/临时路线查询顺路订单,有根据路线查询附近订单,还有查询跨城订单,以及后续的需求乘客查询附近司机,乘客查询顺路司机等。之前这些在线查询接口都在一个单体服务中,多个 RD 会同时负责和修改这个服务的代码,开发效率低下,测试、上线都会相互影响,维护起来比较困难,后来把这些查询按照功能都拆分为不同的子服务,每个 RD 单独负责,大大提高了开发、测试以及运维效率。
重要和非重要的拆分
将核心逻辑和非核心逻辑拆分为不同的微服务,然后采用不同的高可用处理方案,比如核心服务尽量做到机房、集群等多维度的冗余和隔离;非核心服务则可以适当降低可用性标准,出现问题时只要能够及时降级和熔断即可。
变和不变的拆分
按照变更频次对服务进行拆分,尽量将变化聚集到少部分微服务上面,系统的绝大多数服务变更很少,可以减少变更对整个系统的冲击和影响。
版权声明: 本文为 InfoQ 作者【穿过生命散发芬芳】的原创文章。
原文链接:【http://xie.infoq.cn/article/b639381530535dd733f8cad92】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论