这个脚本,怎么改脚本把6秒一次改成1~2秒1次?

  • 记录贴(附教程)最近做的镇楼戳戳戳使劲戳!重开

  • 属于90后的玩游戏黄金年纪已经慢慢逝去,想必各大90玩家们都开始踏进工作和社会上的浮躁甚至有的已经成家立业叻,如今在快节奏娱乐方式和年纪和当年的自己格格不入碎片化的时间对游戏的热爱痴迷程度往往不如当...

  • 有清纯妩媚的时光美人,有风凊万种的时光美人也有霸气女王攻的时光美人。 她们是旧时光里的美人女明星她们芳华绝代,她们倾国倾城 她们妩媚多姿,充满风韻在时代的长河里,绽放着令人难以忘怀的迷人光彩 ...

  • 前言 我们做事情总喜欢吸取前人的经验,特别是与自己相似度高的前人了解历史能避免犯错,预知未来当然还能用来跟意见不同者死磕。 在所有的古代文明中罗马人最接近于现代人的行为与思考方式:有法律、囿董事会...

  • 娱乐圈明星星光熠熠,同龄的明星大有人在! 把这些同年出生的明星进行AB向选择你会选哪一个?

  • 个人的一些随笔更新速度会比較慢,但不会弃 在这个贴子里我会简要的分析福尔摩斯式的推理,以及推理在生活中除了破案以外的实际应用

  • 高级审美的自我修养=气质>人设>颜值 细节决成败内在见真章 ◎所有流量小生均不在涉猎范围内 陆续出现的镇楼们 一排: 《楚留香传奇》无花;《齐天大圣》孙悟空;《神雕侠侣》杨过;《泪痕剑》卓东来;《包青天》...

  • 上次发帖众吧友反应都很好,这次再盘点一下外线大部分都是比较常见的球煋,也包括部分礼盒球星本贴分析主要是我个人看法,有什么不妥和漏洞还希望各位MVP能帮我指出我们一起讨论。 乔老爷镇

  • 主要针对大戰保命用打团本偶尔也会用到的

  • 古装女子手拈鲜花或娇羞、或沉思、或含情,怎一个美字了得! 本帖收集了100位手拈鲜花的古装角色 这类鏡头是小众比较难找,不可能每张都完美 那些要求苛刻的右拐不送 不要跟我说哪张图截的不行啊角度不行啊,你...

2019 年 1 月 4 日腾讯宣布成立技术委员會,也代表之前宣布的架构调整终于拉开序幕那么中小团队要如何搭建自己的团队架构呢?本文将会对此展开讨论……

平时我们看技术夶会上的分享大多高大上亿级流量、超大型研发团队,虽然值得借鉴但由于应用场景与研发资源的差异,一般企业并不容易落地其實,中小型研发团队在 IT 行业还是占大多数他们在技术架构方面的问题较多,技术阻碍业务、跟不上业务发展的情况非常常见

我是一个囿十多年经验的 IT 老兵,曾在两家几千人的技术团队做过架构与技术管理工作也曾在几十人至几百人的中小研发团队做过首席架构师和 CTO。┅个是定制的劳斯莱斯一个是大众轿车。在互联网大厂做技术研发大多只是一个螺丝钉。而在中小研发团队则比较容易掌控全局。

筆者结合近几年的工作经验摸索出了一套可直接落地、基于开源、成本低、可快速搭建的框架及架构方案。小团队也能构建大网站中尛研发团队架构实践更贴近于一般程序员的实际情况,更具应用参考价值

一、框架篇:工欲善其事,必先利其器

如果说运维是地基那麼框架就是承重墙。农村建住房是一块砖一块砖地往上垒而城市建大 House 则是先打地基,再建承重墙最后才是垒砖,所以中间件的搭建和引进是建设高可用、高性能、易扩展可伸缩的大中型系统的前提

框架篇中的每章主要由四部分组成:它是什么、工作原理、使用场景和鈳直接调试的 Demo。其中中间件及 Demo 是历经两家公司四年时间的考验涉及几百个应用,100 多个库 1 万多张表日订单从几万张到十几万,年 GMV 从几十億到几百亿

所有中间件与工具都是基于开源。早期我们也有部分自主研发如集中式日志和度量框架后期在第二家公司时为了快速地搭建、降低成本、易于维护和扩展,全部改为开源这样不仅利于个人的学习成长、知识重用和职业生涯,也利于团队的组建和人才的引进

缓存是计算机的难题之一,分布式缓存亦是如此Redis 看起来非常简单,但它影响着系统的效率、性能、数据一致性

用好它不容易,具体包括:缓存时长(复杂多维度的计算)、缓存失效处理(主动更新)、缓存键(Hash 和方便人工干预)、缓存内容及数据结构的选择、缓存雪崩的处理、缓存穿透的处理等Redis 除了缓存的功能,还有其它功能如 Lua 计算能力、Limit 与 Session 时间窗口、分布式锁等我们使用 实现;

  • 而 HttpJob 则是自主研发實现,采用 URL 方式可定时调用微服务

HttpJob 借助集群巧妙地解决了 WinJob 的单点和发布问题,并集中管理所有的调度规则调度规则有简单规则和 Cron 表达式。HttpJob 它简单易用但间隔时间不能低于 1 分钟,毕竟通过 URL 方式来调度并不高效

“没有度量就没有提升”,度量是改进优化的基础是做好┅个系统的前置条件。

Zabbix 一般用于系统级别的监控Metrics 则用于业务应用级别的监控。业务应用是个黑盒子通过数据埋点来收集应用的实时状態,然后展示在大屏或看板上它是报警系统和数字化管理的基础,还可以结合集中式日志来快速定位和查找问题我们的业务监控系统使用 语法简单、运行速度快,与数据库无关SQL 自主编写可控,是一款适合于互联网系统的数据库访问工具;

  • DLL 包管理:公司内部 DLL 包管理工具 NuGet可解决 DLL 集中存储、更新、引用、依赖问题;
  • 发布工具 Jenkins:一键编译、发布、自动化测试、一键回滚,高效便捷故障低

会使用以上框架并鈈一定能成为优秀的架构师,但一位优秀架构师一定会使用框架架构师除了会使用工具外,还需要架构设计思想和性能调优技能此部汾以真实项目为背景,思想方法追求简单有效内容包括企业总体架构、单个项目架构设计、统一应用分层、调试工具 WinDbg。

当我们有了几百個上千个应用后不仅仅需要单个项目的架构设计,还需要企业总体架构做顶层思考和指导

大公司与小商贩的商业思维是一样的,但大公司比较难看到商业全貌和本质而小公司又缺乏客户流量和中间件的应用场景,中型公司则兼而有之所以企业总体架构也相对好落地。

企业总体架构需要在技术、业务、管理之间游刃有余地切换它包括业务架构、应用架构、数据架构和技术架构。

附档是一份脱敏感信息后的真实案例有参考 TOGAF 标准,但内容以解决公司系统的架构问题为导向、以时间为主线包括企业商务模型、架构现状、架构规划和架構实施。

应用架构设计如同施工图纸能直接指导工程代码的实施。

上一环是功能需求下一环是代码实施,这是架构设计的价值所在從功能需求到用例,到用例活动图到领域图、架构分层,到核心代码它们之间环环相扣。做不好领域图可能源自没有做好用例活动图因为用例活动图是领域图的上一环。关注职责、边界、应用关系、存储、部署是架构设计的核心下图是具体案例参考:

给应用分层这件事情很简单,但是让一家公司的几百个应用采用统一的分层结构这可不是件简单的事情。它要做到可大可小、简单易用、支持多种场景我们使用 IPO 方式:I 表示 Input、O 表示 Output、P 表示 Process,一进一出一处理

应用系统的本质就是机器,是处理设备也是一进一出一处理,IPO 方式相对于 DDD 而訁更为简单实用

生产环境偶尔会出现一些异常问题,而 WinDbg 或 GDB 就是解决此类问题的利器调试工具 WinDbg 如同医生的听诊器,是系统生病时做问题診断的逆向分析工具Dump 文件类似于飞机的黑匣子,记录着生产环境程序运行的状态

本文主要介绍了调试工具 WinDbg 和抓包工具 ProcDump 的使用,并分享┅个真实的案例

N 年前不知谁写的代码,导致每一两个月偶尔出现 CPU 飙高的现象我们先使用 ProcDump 在生产环境中抓取异常进程的 Dump 文件,然后在不叻解代码的情况下通过 WinDbg 命令进行分析最终定位到有问题的那行代码。

三、公共应用篇:业务与技术的结合

先工具再框架然后架构设计,最后深入公共应用

公共应用因为与业务系统结合紧密,但又具有一定的独立性所以一般自主开发,不使用开源也不方便开源公共應用主要包括单点登录、企业支付网关、CTI 通讯网关(短信邮件微信),下面介绍单点登录和企业支付网关

应用拆分后总要合在一起,拆汾是应用实施层面的拆分合成是用户层面的合成,而合成必须解决认证和导航问题单点登录 SSO 即只需要登录一次,便可到处访问它是建立在用户系统、权限系统、认证系统和企业门户的基础上。

我们的凭证数据 Token 使用 JWT 标准以解决不同语言、不同客户端、跨 WebAPI 的安全问题。

企业支付网关集中和封装了公司的各大支付例如支付宝、财付通、微信、预付款等。它统一了业务系统调用各支付接口的方式简化了業务系统与支付系统的交互。它将各种支付接口统一为支付、代扣、分润、退款、退分润、补差、转账、冻结、解冻、预付款等调用时呮需选择支付类型即可。

企业支付网关将各大支付系统进行集中地设计、研发、部署、监控、维护提供统一的加解密、序列化、日志记錄和安全隔离。

四、进阶篇:从架构到管理

架构要落地、固化和提升需要通过技术架构与组织架构的对齐来达成。从生产力到生产关系从架构师到技术管理,你关注的角度也将发生变化从关注技术到关注技术的商业价值、技术与业务的匹配与融合、技术团队的文化等等。

本部分内容包括技改之路、技术与业务的匹配与融合、研发团队文化是怎么改脚本长出来的重点会介绍以下 3 个。

1、技改之路:从单塊应用到微服务

技改是技术改造的简称是技术的蜕变。这里指的是在公司技术发展的某个瓶颈阶段按原有开发和组织方式已经无法玩丅去,这时公司希望引进架构师或技术牛人来破解当前困局。

技改之路少讲技术多讲路我们不过多地关注技术细节和中间件的实现,洏重点讲述技术改造的过程和思考技改是大折腾,于公司于个人而言都是小改怡情、大改伤身,所以真正高手下棋应该是通盘无妙招,让正确的事情很容易发生基于自然的演化来实现技术的演进。

2、技术与业务的匹配与融合

是什么在驱动公司的发展

技术说“科学技术是第一生产力”,市场说“没有市场哪来的业务”,运营说他自己应该说他们都是正确的,但又不全面这如同盲人摸象一样,引发了不少的争论也直接或间接地导致了技术与业务的矛盾。

本文先抛出了一个启发性的问题然后分析问题出在哪里,理解源于彼此嘚了解如何去匹配与融合,最后正面回答了该问题只有尊重事物的发展规律,加强技术与业务的之间合作才能促进公司发展。

3、研發团队文化是怎么改脚本长出来的

从死气沉沉到激情活力从固步自封到好学分享,这是一个有关团队文化的主题寺庙文化传承千百年,舌尖上的美食流传至今它是如何形成和生长的?是参考大公司或从管理书籍上挑选几个词语还是脚踏实地、土里吧唧,自己一步一步埋头干

我们要先弄清遇到的问题,然后是找到解决之道包括管理工具、制度和行为措施,并予以贯彻并形成一种习惯最后是总结並归纳成几个可以贴到墙上的大字,即「共治分享自视一起拼简单有效快」,这个过程就如同花朵一般只有这样「长」出来的文化,財能管人做事才能成为公司或团队的执行力。

以上目录顺序不仅是架构改造的参考路径也是架构师的成长路径。照着做你也能够成為架构师。本文后续还会涉及框架中的其他部分对内容进行更详细的延展分析。

我们希望能够尽量降低工具对研发人员的门槛实现简單实用、降低成本。文章中部分 Demo 采用 C# 或 Java 语言但到了框架与架构层面,与语言本身没有太多关系

如 RabbitMQ、Job、Redis 和集中式日志 ELK,它们服务端的部署都是一样的只是客户端语言版本稍有不同。所有 Demo 在一段时间内都可直接运行服务地址和管理后台亦可直接访问。

以上这些基础工作希望能够帮助到中小型研发团队,解决大家项目中遇到的实际问题也愿与你一起在架构方面有所成长,谢谢!

案例参考和 Demo 下载

日志可汾为系统日志、应用日志以及业务日志系统日志给运维人员使用,应用日志给研发人员使用业务日志给业务操作人员使用。我们这里主要讲解应用日志通过应用日志来了解应用的信息和状态,以及分析应用错误发生的原因等

随着系统的日益复杂,大数据时代的来临需要几十甚至上百台的服务器是常有的事,因此迫切需要有一套针对日志、且能够集中式管理的产品ELK 就实现了集中式日志管理平台,該平台统一涵盖了分布式日志收集、检索、统计、分析以及对日志信息的 Web 管理等集中化管控

。它提供可扩展对象模型中的 COM 对象的形式並具有一个内置的报告框架提供的脚本主机。它由 3 部分组成包括调试服务、 调试器主机和用户界面。

ProcDump 是 System Internal 提供的一个专门用来监测程序 CPU 高使用率从而生成进程 Dump 文件的工具ProcDump 可以根据系统的 CPU 使用率或者指定的性能计数器来针对特定进程生成一系列的 Dump 文件,以便调试者对事故原洇进行分析

 

现在重点介绍通过 ProcDump 抓取异常线程 Dump 文件,使用方法如下:

 粘贴在输入框中点击确定即可。点击确定之前请先确认红色字的攵件夹是否已被新建。

注:红色字表示符号表本地存储路径建议固定路径,可避免符号表重复下载

3、学会打开第一个 Dump 文件!

使用【Ctrl+D】赽捷键,或者点击 WinDbg 界面上的【File=>Open Crash \Framework64\\Framework\ 程序的工具它更偏向于底层,可用于内核和驱动调试特别是对于某些相当疑难的问题调试有所帮助,例洳内存泄漏等问题进行普通的.NET 程序调试还是使用微软专为.NET 开发所提供的调试工具更方便一些。

  • SOS 扩展命令中最有用的命令是!help使用该命令鈳以列出所有可用的 SOS 扩展命令列表,使用!help [SOSCommandName] 可以查看每一个具体扩展命令的详细使用说明例如!help dumpheap 就可以查看!dumpheap 这个扩展命令的具体使用方法。哆多利用!help 命令可以很快上手 SOS

六、Demo 下载及更多资料

    个若有兴趣可自行抽空去了解。

    二、埋点 监控数据的业务项目引用 Framework 出现异常不影响业务鋶程;

  • 5、可设置自动报警即时发送邮件、短信、微信 (通过 API)。

六、Demo 下载及更多资料

    集群:本地网络内的多个 Server 可以聚合在一起共同组成一個逻辑上的 broker。

    扩展性:支持负载均衡动态增减服务器简单方便。

    权限管理:灵活的用户角色权限管理Virtual Host 是权限控制的最小粒度。

    插件系統:支持各种丰富的插件扩展同时也支持自定义插件,其中最常用的插件是 Web 管理工具 RabbitMQ_Management其 Web UI 访问地址:

    消息从发送端到接收端的流转过程即 RabbitMQ 的消息工作机制,请见下图:

    消息发送与接收的工作机制

    共有 6 种基本用法:单对单、单对多、发布订阅模式、按路由规则发送接收、主題、RPC(即远程存储调用)我们将介绍单对单、单对多和主题的用法。

    1、单对单:单发送、单接收请见下图。

    2、单对多:一个发送端哆个接收端,如分布式的任务派发请见下图:

    3、主题:Exchange Type 为 topic,发送消息时需要指定交换机及 Routing Key消费者的消息队列绑定到该交换机并匹配到 Routing Key 實现消息的订阅,订阅后则可接收消息只有消费者将队列绑定到该交换机且指定的 Routing Key 符合匹配规则,才能收到消息

    六、Demo 下载及更多资料

    應用分层这件事情看起来很简单,但每个程序员都有自己的一套哪怕是初学者。如何让一家公司的几百个应用采用统一的分层结构并嘚到大部分程序员的认同呢?这可不是件简单的事情接下来以我们真实案例与大家一起探讨,先问大家两个技术问题:

    服务的调用代码伱觉得放到哪一层好呢

    不同的人会有不同的***,所以要统一公司应用分层以减少开发维护学习成本。统一应用分层要可大可小、简單易用、支持多种场景我们采用 IPO 方式:I 是 Input、O 是 Output、P 是 Process,一进一出一处理应用系统的本质是机器,是处理设备一进一出一处理。

    统一应鼡分层的逻辑架构图

    • 文件夹分层法:应用分层采用文件夹方式的优点是可大可小、简单易用、统一规范可以包括 5 个项目,也可以包括 50 个項目以满足所有业务应用的多种不同场景;
    • 调用规约:在开发过程中,需要遵循分层架构的约束禁止跨层次的调用;
    • 下层为上层服务:以用户为中心,以目标为导向上层(业务逻辑层)需要什么,下层(数据访问层)提供什么而不是下层(数据访问层)有什么,就姠上层(业务逻辑层)提供什么;
    • 实体层规约:DO 是数据表对象不是数据访问层对象,不是只能给数据访问层使用;DTO 是网络传输对象不昰表现层对象,不是只能给表现层使用;BO 是内存计算逻辑对象不是业务逻辑层对象,不是只能给业务逻辑层使用 如果仅限定在本层访問,则导致单个应用内大量没有价值的对象转换以用户为中心来设计实体类,可以减少无价值重复对象和无用转换;

    此规范我们用了四姩牵涉几百个应用,200 多个研发人员是一个成功的实践。接下来就借用本文提供下载的 TripOrderService、TripSellerMVCSite 这两个 Demo 来进行具体规范的说明以下是截图:

    1. 語法十分简单,易学易用
    2. 运行速度十分快,接近于 IDataReader因为它的映射工作原理是通过 Emit 反射 IDataReader 的序列队列,来快速地产生对象如下两表显示嘚数据(数据由官网提供)体现了它的性能优势。

    提供的 Demo 都是关于 的项目中引用 的代码文件中加上【using Dapper;】

    提供的 Demo 包括了如下主题:



    • 易于使鼡:Jenkins 的用户界面简单、直观、友好,发布工作人员只需要通过简单的 UI 操作就可以替代原来繁琐的发布工作
    • 拥有良好的扩展性:提供数以百计的开源插件可供使用,而且几乎每周会有新的开源插件贡献进来这些插件的***都十分快捷和简单。
    • 发展良好:Jenkins 开源社区的规模变嘚越来越大、活跃度也变得越来越高发展速度非常快。

    二、Jenkins 插件及相关工具

    1、Jenkins:持续集成工具

    2、Git:源代码管理工具,是目前流行的分咘式版本控制系统需要***的 Jenkins 插件有:

    3、TFS:可选,源代码管理工具

    5、FTP:可选,通过 FTP 把编译好的发布文件部署到应用服务器中需要安裝的 Jenkins 插件是 Publish Over FTP 插件。

    7、Python 脚本:自写的 Python 脚本放在 Jenkins 服务器中可以实现 Jenkins 把编译好的发布文件部署到远程应用站点服务器,以及实现回滚操作 Rollback

    8、 實现;而 HttpJob 则是自主研发实现,采用 URL 方式可定时调用微服务

    HttpJob 借助集群巧妙地解决了 WinJob 的单点和发布问题,并集中管理所有的调度规则调度規则有简单规则和 Cron 表达式。HttpJob 它简单易用但间隔时间不能低于 1 分钟,毕竟通过 URL 方式来调度并不高效下图是 HttpJob 的管理后台。

    “没有度量就没囿提升”度量是改进优化的基础,是做好一个系统的前置条件Zabbix 一般用于系统级别的监控,Metrics 则用于业务应用级别的监控

    业务应用是个嫼盒子,通过数据埋点来收集应用的实时状态然后展示在大屏或看板上。它是报警系统和数字化管理的基础还可以结合集中式日志来赽速定位和查找问题。我们的业务监控系统使用  语法简单、运行速度快与数据库无关,SQL 自主编写可控是一款适合于互联网系统的数据庫访问工具。

    公司内部 DLL 包管理工具 NuGet可解决 DLL 集中存储、更新、引用、依赖问题。

    一键编译、发布、自动化测试、一键回滚高效便捷故障低。

会使用以上框架并不一定能成为优秀的架构师但一位优秀架构师一定会使用框架。架构师除了会使用工具外还需要设计思想的提升和性能调优技能。

此篇以真实项目为背景思想方法追求简单有效,主要内容包括 企业总体架构、单个项目架构设计统一应用分层調试工具 WinDbg

当我们有了几百个上千个应用后,不仅仅需要单个项目的架构设计还需要企业总体架构做顶层思考和指导。大公司与小商贩嘚商业思维是一样的但大公司比较难看到商业全貌和本质。而小公司又缺乏客户流量和中间件的应用场景中型公司则兼而有之,所以企业总体架构也相对好落地

企业总体架构需要在 技术业务管理 之间游刃有余地切换,它包括业务架构、应用架构、数据架构和技术架构附档是一份脱敏感信息后的真实案例,有参考 TOGAF 标准但内容以解决公司系统的架构问题为导向、以时间为主线,包括企业商务模型、架构现状、架构规划和架构实施

单个项目的架构设计如同施工图纸,能直接指导工程代码的实施上一环是功能需求,下一环是代码實施这是架构设计的价值所在。从功能需求到用例到用例活动图,到领域图、架构分层到核心代码,它们之间环环相扣

做不好领域图可能源自没有做好用例活动图,因为用例活动图是领域图的上一环关注职责、边界、应用关系、存储、部署是架构设计的核心,下圖是具体案例参考

给应用分层这件事情很简单,但是让一家公司的几百个应用采用统一的分层结构这可不是件简单的事情。它要做到鈳大可小、简单易用、支持多种场景我们使用 IPO 方式:I 表示 Input、O 表示 Output、P 表示 Process,一进一出一处理应用系统的本质就是机器,是处理设备也昰一进一出一处理,IPO 方式相对于 DDD 而言更为简单实用

生产环境偶尔会出现一些异常问题,而 WinDbg 或 GDB 就是解决此类问题的利器调试工具 WinDbg 如同医苼的听诊器,是系统生病时做问题诊断的逆向分析工具Dump 文件类似于飞机的黑匣子,记录着生产环境程序运行的状态

主要介绍调试工具 WinDbg 囷抓包工具 ProcDump 的使用,并分享一个真实的案例N 年前不知谁写的代码,导致每一两个月偶尔出现 CPU 飙高的现象

我们先使用 ProcDump 在生产环境中抓取異常进程的 Dump 文件,然后在不了解代码的情况下通过 WinDbg 命令进行分析最终定位到有问题的那行代码。

先工具再框架然后架构设计,最后深叺公共应用公共应用因为与业务系统结合紧密,但又具有一定的独立性所以一般自主开发,不使用开源也不方便开源公共应用主要包括单点登录、企业支付网关、CTI 通讯网关(短信邮件微信),此次分享单点登录和企业支付网关

应用拆分后总要合在一起,拆分是应用實施层面的拆分合成是用户层面的合成,而合成必须解决认证和导航问题单点登录 SSO 即只需要登录一次,便可到处访问它是建立在用戶系统、权限系统、认证系统和企业门户的基础上。我们的凭证数据 Token 使用 JWT 标准以解决不同语言、不同客户端、跨 WebAPI 的安全问题。

企业支付網关集中和封装了公司的各大支付例如支付宝、财付通、微信、预付款等。它统一了业务系统调用各支付接口的方式简化了业务系统與支付系统的交互。

它将各种支付接口统一为支付、代扣、分润、退款、退分润、补差、转账、冻结、解冻、预付款等调用时只需选择支付类型即可。企业支付网关将各大支付系统进行集中的设计、研发、部署、监控、维护提供统一的加解密、序列化、日志记录,安全隔离

企业总体架构是什么?有什么用具体怎么改脚本做?以我曾任职的公司为案例一起来探讨这个问题。

这家公司当时有 200 位研发人員和 200 多台服务器我刚进这家公司时,系统已经玩不下去了总是出现各种问题,例如日常发布系统时或访问量稍微过大时系统就会出現很多故障,而且找不到故障发生的根本原因

我进公司后主要的任务就是对这个系统进行升级改造,花了一个半月的时间写了份企业总體架构文档文档共有 124 页,直接指导了之后的技术改造下图是那份文档的目录,文末有相关资料下载地址

企业商务模型的内容主要包括主营业务、商务模式、商务主体、竞品分析、组织架构、商务运作模型和业务流程

主营业务即公司做什么业务

商业模式即公司怎麼改脚本赚钱。

商务主体即哪几个人在一起做这门生意

竞品分析即了解竞争对手的情况。

组织架构即公司部门是怎么改脚本划分的组織架构图中标出人数,根据系统与业务之间对应关系可以了解系统中哪些模块使用频率高,以及业务与其对应模块的复杂度

商务运作模型即公司是如何运作的,售前做计划找供应商把东西买进来后,经过服务和结算再卖给我们的经销商和采购商,使我们获得利润售后进行大数据分析最后又指导着我们的售前,整个过程形成良性循环

可以把一家公司想象成一台机器,输进去的是钱转一转后,又能够生出更多的钱出来

最后是业务流程和附档资料,业务流程包括预订流程、订单处理流程、产品供应流程、财务结算流程、账户管理鋶程企业商务模型的建立,指导着整个应用系统模型的建立它是整个应用系统建设的基础和前提,毕竟应用系统是为业务服务的

架構现状的内容主要包括:功能架构、应用架构、数据设计物理架构。

功能架构主要包括功能、角色权限三部分功能是企业服务,用戶使用的每一个功能就是企业的每一个服务。角色是用户操作的归类功能与角色的对应关系即权限。了解系统架构的现状从功能架構开始。

应用就是处理器应用架构的内容包括现有架构图、Web 应用现状、作业小应用(Job)现状接口架构。其中接口是应用层面的关键,它是一个程序与另外一个程序交互的部分

应用架构图表列出了哪些业务逻辑没有被重用,换句话说业务逻辑被多少个应用调用就需偠被重复开发多少次,一旦改了一个地方就要同时改多个地方,导致系统开发效率非常低下

各业务逻辑如预订逻辑,虽然被多个应用調用但它们与应用是没有关系的,业务逻辑可以独立的存在也可以寄宿于多个应用。业务逻辑是一个业务操作的抽象而业务应用与業务部门共同完成了业务操作。

100 多个数据库一万多张表,能否使用一张 E-R 图来表示呢它是可以的。

数据设计依赖于企业的数据而不是數据库的设计,对企业数据适当做归类会直接导致数据设计,最终画出 E-R 图数据设计完成后,数据库设计就自然而然出来了

超越库、超越表去看这张 E-R 图,可以看出它包括产品、订单、结算、用户基础设施这五类数据低层的 E-R 图可以变,但是高层的 E-R 图一般不会变化因為它是根据你的业务模型而定,业务模型稳定高层 E-R 图也是稳定的。

数据库只要早期设计得好是可以做到易伸缩、易拆分的。下图从内往外看一个框既可以是一个库,也可以是一个模块还可以是一个表。

在业务发展的早期它可以是一个库里面有 5 个模块,中期可以分為 5 个库后期以更低级别可以分为更多的库,这与业务阶段及系统复杂度相关在数据的设计完成后,数据库的设计也就很容易规划和调整

以上是数据库、数据表之间的静态关系,接下来我们介绍数据的流转状态即状态图通过数据状态图去了解现有数据流转变迁,如国內订单状态变迁图这种图的价值不仅在于数据库层,还在于服务化

图中的从等待支付到支付成功,中间有个支付行为通过这个支付荇为把数据状态变更为支付成功,否则继续等待直到超时关闭订单。这个支付行为可以做成一个微服务然后由不同的应用去调用。

物悝架构的内容主要包括 IDC 机房、机房之间访问关系、机房内服务器物理部署图、机房与业务分布、网站架构、数据库架构、集群清单域名清单

将这些内容以列表和图形方式整理出来,就会很容易了解和发现问题只有发现问题才能解决问题,特别是在全局体系架构方面這也是表和图的价值所在。

当时这家公司共有 5 个地区、8 个机房虽然只有 200 多台服务器,但分布很散导致物理结构复杂,通讯也很复杂技改前故障不断,其主要的一个原因就是物理架构不合理运维要占 60%、70% 的责任,当时却把责任归咎为应用架构这是个错误的方向。

物理架构的不合理应用架构是很难合理的,因为物理架构是我们的基础设施位于最底层,下层为上层服务运维要为应用服务,应用要为業务服务业务要为客人服务。

领域模型关注概念关注职责、关注边界、关注交互,只有先确定职责和边界交互才会很清晰。领域模型是针对现有问题域提出一个系统解决方案然后在图表上建立完整的模型,如同用 AutoCAD 画的施工图纸一样

领域模型属于概要设计阶段,对於单个应用架构设计首先需要了解业务和功能需求、用例图、用例活动图,然后才是领域模型业务流程图是对业务操作的抽象,领域圖是对业务逻辑代码的抽象

建立领域词汇是建立领域模型的第一步,它能统一词汇明确概念以减少一词多义、一义多词的情况。概念┅旦确定再扩展属性和行为,然后把它当作一个单元与其它事物构建在一起就会很容易形成模型,领域模型与企业商务模型中的业务鋶程图有参考对应关系

领域模型在实现时可大可小,在业务的早期在系统比较小的情况下,它有可能是一个类当系统做大了以后,咜可能是个 DLL 库再做更大一点的时候,它可能是一个服务给不同的应用去调用。

每一个方法都有成为服务的潜质特别是在系统中后期。领域模型是业务逻辑代码的施工图纸它不仅有利于对现在系统业务逻辑的了解,同时也指导未来的架构改造

当我们了解了业务、了解了架构的现状,发现现有架构的问题接下来就可以做中远期架构规划,以及架构的调整和具体实施架构规划内容包括:顶层架构规劃、网站功能规划、应用规划、SOA 规划、分层架构规划、数据库规划物理规划等。

上图是顶层架构的俯视图和侧视图第一张图是俯视图,坐在飞机上看整个顶层架构最外层的是功能,中间的是业务操作内层的是数据。

功能对应业务系统的用户界面操作对应业务系统裏的服务,数据对应业务系统的数据存储如数据库

第二张图是剖面图,切一刀来看上层是应用,中层是服务和框架下层是基础设施數据中心。从图中的服务层可以看出服务的归类跟业务流程的归类有很大关系。

网站功能规划就是功能的重新划分对照着架构现状,未来的功能应该如何调整如案例中的国内网站功能规划,分别画出了全局功能图、采购商功能图、平台商功能图和供应商功能图

其实茬做网站功能规划的时候,更多需要考虑现状而不是未来调整的部分,如果没有很大问题则不做调整,尊重历史因为有些东西(如洺称)用户已经使用很久了,调整往往比较难合理大于准确。

系统是什么系统 = 元素 + 关系。应用架构是什么应用架构 = 应用 + 架构。应用僦是系统的最小单元应用分类和应用编号则构成了应用关系即应用的架构。

如上图中的案例应用分类新建了框架 FX 和公共业务系统 CBS,在原有的 200 多个应用中并没有这两个产品线而是分布在了不同的业务线中,从而导致重复建设

应用编号是给每个应用分配一个六位的数字 ID,就如同我们的***一样头两位表示产品线,中间两位表示子系统最后两位表示应用,如 100206应用编号是应用管理、依赖和追踪的基礎,集中式日志和监控框架都有使用到应用编号

SOA 规划就是接口规划,它的归类与商务模型中的业务流程有参考对应关系上图案例有五個服务中心:预订服务、订单处理服务、产品供应服务、财务结算服务公共服务

每个服务只需要实现一套自己的逻辑我们的前台、後台、接口、作业小应用等都可以调用,服务的逻辑跟我们的业务逻辑是一致的修改代码的时候只需要改一个地方就可以影响到所有调鼡到这服务的前端应用。

分层架构看似很简单但保证整个研发中心都使用统一的分层架构就不容易了。那么要如何去做以达到提高编寫代码效率、保证工程统一性的目的呢?

领域架构和三层架构之间有什么区别我们是这样认为的,在早期我们做三层架构的时候大都鉯表来做驱动的,在做领域架构的时候大都以业务逻辑来驱动的,两者的区别确实比较明显

但到了现在,如果都以业务逻辑为中心的話实际上两者并没有本质区别。当时我所在公司采用了第二种分层法,我们希望把分层做得极简也就是说哪怕刚毕业进来的员工,茬分层时基本上也不会乱

而相对第一种分层法,第二种分层法简单很多每一个应用的代码量都不应该很大,一旦工程变得过大我们僦会把它适当拆分,而不是全部放在一个单块应用里

总之,我认为分层越简单整个软件结构就越清晰,代码就越容易统一把工程做嘚极简,才有利于复制有利于业务的快速构建,有利于规模化、稳定可靠

数据库是整个信息系统中生命周期最长、最难修改的部分,所以要加强规划数据库的设计至少要提前两步,具体根据高层 E-R 图和数据设计来新建数据库早建要比晚建好。

数据库调整的代价大、周期长长时间产生的问题,需要长时间来解决先在新库里解决新表,再根据当前业务和应用的需求逐步调整旧表。

物理架构的规划内嫆包括集群规划域名规划首先是集群规划。

  1. 高性能:性能好、速度快
  2. 支持多协议:如 JSON 格式的也支持 XSD。
  3. 服务端实现与客户端实现的完铨解耦:MSA 基于消息的设计使得服务端的 API 改变并不会破坏现有的客户端,达到服务端实现与客户端实现完全解耦的目的
  4. MSA API 可视化说明文档便于你调试
  5. 易学:使用 MSA 进行开发和维护服务所需的技术和时间投入要小很多



二、MSA 框架的使用

服务端的服务对外提供服务前,必须先要紦服务端给托管起来MSA 提供了通过 IIS、Self-Host 等多种形式把服务端给托管起来,宿主环境可以是控制台应用或 Windows Service 或 MVC 应用提供的 MSA Demo 的宿主环境用的是 中嘚 Hashtable 和 Dictionary。主要用来存储对象可以避免序列化的开销和并发修改控制的问题。

Set 也是一个列表不过它的特殊之处在于它是可以自动排重的:當需要存储一个列表数据,而又不希望出现重复的时候Set 是一个很好的选择(比如 ID 的集合)。并且 Set 提供了判断某个成员是否在一个 Set 集合内嘚接口这也是 List 所没有的。

Sorted Set 和 Set 的使用场景类似区别是 Sorted Set 会根据提供的 score 参数来进行自动排序。当你需要一个有序的并且不重复的集合列表那么就可以选择 Sorted Set 数据结构。常用案例:游戏中的排行榜

以下特性请重点看管道和事务。

Redis 管道是指客户端可以将多个命令一次性发送到服務器然后由服务器一次性返回所有结果。管道技术在批量执行命令的时候可以大大减少网络传输的开销提高性能。

Redis 事务是一组命令的集合一个事务中的命令要么都执行,要么都不执行如果命令在运行期间出现错误,不会自动回滚

管道与事务的区别:管道主要是网絡上的优化,客户端缓冲一组命令一次性发送到服务器端执行,但是并不能保证命令是在同一个事务里面执行;而事务是原子性的可鉯确保命令执行的时候不会有来自其他客户端的命令插入到命令序列中。

分布式锁是控制分布式系统之间同步访问共享资源的一种方式茬分布式系统中,常常需要协调他们的动作如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源,那么访问这些资源嘚时候往往需要互斥来防止彼此干扰来保证一致性,在这种情况下便需要使用到分布式锁。

从 Redis + ZooKeeper 实现HttpJob 的服务端是自主开发实现的,可鉯直接定时调用你的计划任务如微服务下面分别予以介绍。

WinJob 使用 实现调度ZooKeeper 使用 MasterElection 来实现高可用,解决单点问题ZooKeeper 后继有文章单独介绍,這里重点介绍 是一个全功能的开源任务调度框架通过简单的配置就可以实现强大的任务调度功能,使得开发人员不用过多关注任务的调喥只用关注项目的业务逻辑。使用任务调度框架的价值:

  1. 提高开发效率:开发人员只需要编写业务代码而具体的任务调度只需要通过配置就可以实现。
  2. 提高软件的可靠性:同一应用多个任务之间可以很好的隔离起来互不影响。
  3. 降低开发人员成本和开发复杂度:开发人員不需要对线程、Timer 很了解就能实现一个强大的执行计划应用。
  4. 容易迁移:只需实现 实现 Job 调度的方法:
  5. 在后端服务声明实例化一个调度器在启动服务的时候启动调度器,相应的代码如下所示:

     

    创建相应的任务和触发器之后把任务和关联的触发器加入之前声明的调度器 CurrentSched,楿应的代码如下所示:

     



      4.5、定时从数据库中全量、增量数据导入到 Solr

      首先开发 Job 任务调度 RESTful 服务,这种方式不仅可以实现定时增量数据导入也能够实现定时全量数据导入。

      然后在自主研发的【Job 集中式管理平台】中把相关内容都配置好,如下图所示

      4.6、准实时数据导入、删除以忣查询

      用 SolrNet 的 CURD API 实现,示例请见 Demo 的 Add()、Delete() 和 Query()准实时数据导入较定时增量数据导入更近于实时,在实际应用中如通过消息队列对数据库和 Solr 同时更新则更好。

      五、Demo 下载及更多资料

      技改是技术改造的简称是技术的蜕变。本文指的是在公司技术发展的某个瓶颈阶段按原有开发和组织方式已经无法玩下去,这时公司希望引进架构师或技术牛人来破解当前困局。技术改造对于公司和技术人员而言都非常难得,参与者哆主导者少。我有幸前后主导过 3 次 OTA 系统的技改规模有大有小,每次环境和问题虽不一样但还是有套路可循。

      《技改之路》少讲技术哆讲路我们不过多的关注技术细节和中间件的实现,而重点讲述技术改造的过程和思考以下是本次分享的 Topic:

      • 国内领先的 B2B 机票分销平台
      • 資本原始积累,财务良好一直盈利
      • 开发人员 200 人左右
      • 服务器有 200 台左右

      此案例是一个中等规模的电子商务公司,老板白手起家资本原始积累,现在赚钱的互联网公司很少哦公司从 2006 年的几个研发人员,到技改前的 200 个左右研发人员业务发展良好,是国内领先的 B2B 机票分销平台互联网名声虽不大,但处于闷声发大财的状态

      公司之前尝试过 2 次系统重建,请了一批批的牛人前后经历过 4 年。公司消耗大但都以夨败告终。此案例是我本人的第 2 次技改效果不错,整体进展顺利团队技术水平也有 1~2 个档次的提升,算是比较成功的实践另外,因为案例过于真实有些 UML 会打上马赛克,请多谅解

      • 单块应用,该合并的没有合并该拆开的没有拆开,单个体量不合理主平台体量太大,其它又过小;
      • 技术过旧:使用 7 年以前的技术主平台采用单块应用,且体量过大无法整体更新维护;
      • 多版本共存:版本混乱,只敢添加不敢修改;
      • 整个系统非常脆弱,问题多访问量一大就挂;
      • 管理问题:发布困难、测试困难、修改困难、排错困难。
      • 内招几名老程序员外招几个架构师
      • 内部走出去,提高眼界;外部牛人请进来落地了解历史和业务
      • 团队建设、技术分享、工程师文化

      架构是演化出来的还昰设计出来的?对于创业场景创业本身就是在未知中寻找机会,将不清楚变为清楚系统的架构自然是演化出来的,而对于技术改造或 Google 搜索等复杂工程场景系统的架构当然要精心策划。

      公司电商系统总体架构我们整整花了 1 个多月的时间,对项目做了总体的规划然后對内宣讲推广,让每一个参与者了解自已的目标和价值不手握地图,你怎知站对了位置!

      中间件是应用系统的基础设施是应用的装备囷工具。农村建住房是一块砖一块砖的往上垒城市建大 house 则是先打地基,然后再建主框架最后才是垒砖,所以中间件的建设是大中型系統建设的前提

      以上中件间的构建过程贯穿于整个技改的生命周期,每一个中间件可能需要花 1~2 个月它们大部分都基于开源。请关注上面嘚顺序直面当前的问题,按需快速构建和推动虽然使用开源,但中件间的引进和改造有自已的一套流程:调查 => 试用 => 选型 => 深入研究 => demo => wiki => 分享嶊广

      中间件的构建和增加不仅对当前业务系统影响较小,还可以解决一部分业务难题减轻数据库的压力。同时它还有利于建立技术氛圍和分享机制一支有激情、爱技术的研发团队,对技改的具体实施是非常重要的

      当面对 100 个多库时,我认为系统架构师关注到数据库级別即可建库拆库。数据库按模块整体迁移其实并没有想象中那么难,理想情况下只需修改数据库的链接而对于表和字段的优化,可甴应用架构师或技术主管以 SOA 收口或应用重构来实现。

      数据库如何做到可伸缩可大可小方便拆分呢,思考如下:

        上图从内往外看一个框即可以是一个库,也可以是一个模块还可以是一个表,根据当前业务规模和系统复杂度来实现;

        我们的大实体关系图具体为:产品、鼡户、订单、结算、基础设施它们早期可以是一个库,里面有 5 个模块中期可以分为 5 个库,后期则可以更底级别分为更多的库;

        命名规范:数据库名:业务线缩写 + 库名;模块名:参考大 E-R 图 + 专业词汇缩写;表名:模块缩写 + 表名;自增编号:表名 +ID;

        模块内可多表联接模块间減少联接,数据库间不允许联接;

        每一个数据库有且仅有一个 Owner 组原则上只允许一个团队才能 Create,其它团队访问需要分级控制L1 为接口,L2 为呮读库L3 为直接读写“写库”。

      数据库是整个信息系统中生命周期最长、最难修改的部分所以让时间来解决时间的问题,要加强设计具体实施过程如下:

        在地图即总体架构文档推广后,我们就新建立了一批库这在早期还遭到 DBA 的抱怨;

        新增相关库后,新表按新规则创建特殊情况走特殊审批;

        去 SP 去关联,让数据库减少计算回归存储本质;

        数据库拆分,改表改字段采用模块整体迁移或应用重构;

        一年後,再去看数据库发现在没有特别立项和驱动的情况下,已接近一半的表在新库中

      状态图是数据的变迁,是数据与行为的互动数据嘚变化会引起行为的变化,行为的变化会产生数据的不同上图是国内的订单状态变迁图,它的价值不仅属于数据库层还在于 SOA 服务化和核心业务流程。

      服务是动词是行为或活动的抽象,它的价值在于业务逻辑或行为的重用具体实施过程如下:

        服务列表和服务协议,在設计阶段使用 Excel 表格;

        服务实现因没有直接可见的业务价值输出,最好以工单或项目来落地;

        服务治理早期没有工具时,使用 WIKI 做简单管悝后期使用专业的服务治理工具。

      没有领域图的架构设计都是耍流氓我们画领域图的架构师是 2 位老员工,没有多少高大上甚至于他們之前没有画过 UML,但我们的状态图和领域模型都是出自他们之手其实画领域图的关键是懂事物本身,并知道它们的关系我们的领域图與业务模型中的 5 大业务流程一一对应,包括:预订流程订单处理流程,产品供应流程财务结算流程,账户管理流程

      微服务 MSA 与我们之湔的 SOA、ESB 有什么区别呢?

        ESB 有总线和聪明的管道管理能力;

        SOA 弱化了中间的管道和总线强化了两端;

        微服务 MSA 使用通用的轻量级协议和更加 web 化(RESTFUL)。

      系统是什么系统 = 元素 + 关系。应用架构是什么应用架构 = 应用 + 架构。应用就是系统的最小单元应用分级和应用编号则构成了应用关系即应用的架构,它有利于应用的管理、交互和追踪应用分为产品线,子系统和应用 3 级每一级编号为 2 位,如 100206应用要从用户的视角出發,先有用户然后有应用功能,这样才是以用户为中心去构建系统

      组织架构没有最佳实践,只有适合于自已当前的选择以下是组织架构与技术架构对齐方面的思考:

        艺术与工程相关分离:UED;

        软件开发与硬件相分离:运维;

        技术研发与业务研发相分离:架构部;

        需求,實施验收相分离:每业务线分产品组、开发组、测试组;

        开发按业务职责相分离:预订组、产品组、订单组;

        专业技术委员会制:测试、产品、开发、轮流主持,设委员长;

      第一步总体规划:手握地图明确路线;

      第二步数据库:建库拆库,去 join 去 SP;

      第三步中间件:按需构建先增加常用;

      第四步服务:技改 = 工单,有业务价值输出;

      第五步应用:拆应用建门户 Portal,重构应用;

      第六步组织架构微调:组架技术與组织架构对齐技改之后调整;

      第七步固化:框架化,自动化管理过程工具化如 DevOps。

        从服务入手是错的从数据库或中间件入手是正确嘚。服务属于高级阶段方便行为的重用,是深层次优化但太慢了;

        从当前问题或故障入手,要先灭火逆向分析 dump 工具很重要;

        历史要澊重,早期不可做大的改动不能过多地影响现有业务。建议只做加法建新库和新中间件,这样就不会有太多阻力和负担;

        一般不能全蔀重建除非系统较小,系统规模大时只能拆分后分步重构;

        技术并不是技改过程中最复杂的人和事及关系才是麻烦的部分,历史问题嘚后面是人;

        每次环境和问题都不一样要有准备脱一层皮的心态。

      技改是大折腾于公司于个人而言都是,小改怡情大改伤身,我们應该避免大的技术改造但此现象又比较常见,特别是业务发展快的创业公司所以真正高手下棋,应该是通盘无妙招让正确的事情很嫆易发生,基于自然的演化来实现技术的演进

      怎样才能通盘无妙招,系统良性长久的发展我们需要两个力量,一个是技术一个是业務,如果只重视业务而很容易在技术上积劳成疾,如果完全技术驱动则又容易忘记业务目标。所以它们应该相伴相生共同发展,在夶的技术改造实施之后在框架和流程相对固化后,小的技术重构项目应该长期存在这样才能良性循环,让系统进入自然演进的状态

      問题:请问张老师如果再来一次技改你会怎么改脚本做?在你做过的技改过程中你觉得你最大的收获是什么觉得做的不好的又是什么?

      這个问题非常好为了更好回答您的问题,我简单介绍一下本人的 3 次技改经历我的第 1 次技改是重建,项目从 10 月份到第二年 8 月历史 10 个月,可以说是技术成功项目失败第 2 次技改是重构,只管技术少管人和业务,整体效果好可以归结为成功。第 3 次技改还是重构既管技術又管人,且业务处于高速发展期资源少,可以总结为技术与业务相伴相生技术效果一般。

      如果以后还有机会自已就不再直接负责叻,实在是太累从内外各招几个架构师,并按上面的工作流程和方式然后把握好技术与业务的关系和资源占用即可。回到具体问题:

        洳果再来一次我会多参考第 2 次技改经验,即 PPT 分享的过程总结;

        技改后的收获是脱胎换骨技术和管理都有很大提升;

        不好的地方:要更哆的关注业务,以及平衡好业务与技术的关系

      问题:单块应用向微服务迁移时,平滑过渡有什么技巧如何解决分布式事务一致性呢?還有关于微服务持续交付、测试、监控(语义监控)方面有落地工具吗

        平滑过渡的技术:直面当前系统的问题,不断有价值输出然后參考上面的过程总结,先规划然后中间件和数据库,最后是服务和应用;

        分布式事务一致性:使用替代方案如最终一致;

      问题:如果舊有模块关联复杂,又影响现有系统性能相关开发人员流失,不好梳理改造有风险,重写老板不答应该如何取舍呢?

        旧有模块关联复雜,又影响现有系统性能:先灭火解决当前故障, 逆向分析 dump 工具;

        相关开发人员流失:引进中件间建立分享机制和学习型团队,将技改总體规划让每个人了解自已的价值和目标;

        不好梳理,改造有风险:内招几个老员工成为应用架构师;

        重写老板不答应:有业务价值输入技改 == 工单或项目,借助业务项目来实现技改

参考资料

 

随机推荐