关键词：
如果你正好处在中小型研发团队……
中小型研发团队很多，而社区在中小型研发团队架构实践方面的探讨却很少。中小型研发团队特别是 50 至 200 人的研发团队，在早期的业务探索阶段，更多关注业务逻辑，快速迭代以验证商业模式，很少去关注技术架构。
这时如果继续按照原有的架构及研发模式，会出现大量的问题，再也无法玩下去了。能不能有一套可直接落地、基于开源、成本低，可快速搭建的中间件及架构升级方案呢？
我是一个有十多年经验的 IT 老兵，曾主导了两家公司的技术架构升级改造，现抛砖引玉，与大家一起探讨这方面的问题。
在接下来的一段时间里，我会陆续推出此系列文章。
根据我们以往的经验，分享者主讲一个小时左右，业务研发就可以快速地进入项目实战。对于后面新加入的团队成员，也可通过 WIKI 自主快速学习。这是我们之前对自己的要求，尽量降低工具对人员的要求，简单实用、降低成本。
文章中部分 Demo 采用 C# 语言, 但到了框架或架构层面，与语言本身没有太多直接的关系。如 RabbitMQ、Job、Redis 和集中式日志，它们服务端的部署是一样的，只是客户端语言版本稍有不同。
所有 Demo 都可直接运行，服务地址及管理后台也可直接访问。因为部署在公有云，牵涉到成本费用的问题，我计划持续到明年 3 月底。
这些小小的基础工作，希望能够帮到中小型研发团队，解决大家项目中遇到的实际问题。愿与你一起成长，你的分享和点赞是我此次付出的动力，谢谢！
整个系列文章分为三个部分，包括 框架篇、架构篇 和 公共应用篇。
-
框架篇 即中间件或工具的使用，如缓存、消息队列、集中式日志、度量、微服务框架等，工欲善其事，必先利其器。
-
架构篇 主要是设计思想的提升，有企业总体架构、单个项目架构设计、统一应用分层等。
-
公共应用篇 是业务与技术的结合，有单点登录和企业支付网关。
以下是篇章的具体介绍：
框架篇——工欲善其事，必先利其器
如果说运维是地基，那么框架就是承重墙。农村建住房是一块砖一块砖地往上垒，而城市建大 House 则是先打地基，再建承重墙，最后才是垒砖，所以中间件的搭建和引进是建设高可用、高性能、易扩展可伸缩的大中型系统的前提。
框架篇中的每篇主要由四部分组成：它是什么、工作原理、使用场景 和 可直接调试的 Demo。其中 Demo 及中间件历经两家公司四年时间的考验，涉及几百个应用，100 多个库 1 万多张表，日订单从几万张到十几万，年 GMV 从几十亿到几百亿。
所有中间件及工具都是基于开源，早期我们也有部分自主研发如集中式日志和度量框架。后期在第二家公司时为了快速地搭建，降低成本，易于维护和扩展，全部改为开源。这样不仅利于个人的学习成长、知识重用和职业生涯，也利于团队的组建和人才的引进。
集中式缓存 Redis
缓存是计算机的难题之一，分布式缓存亦是如此。Redis 看起来非常简单，但它影响着系统的效率、性能、数据一致性。
用好它不容易，涉及到的问题包括：缓存时长（复杂多维度的计算）、缓存失效处理（主动更新）、缓存键（Hash 和方便人工干预）、缓存内容及数据结构的选择、缓存雪崩的处理、缓存穿透的处理等。
Redis 除了缓存的功能，还有其它功能如 Lua 计算能力、Limit 与 Session 时间窗口、分布式锁等。
消息队列 RabbitMQ
消息队列好比葛洲坝，有大量数据的堆积能力，然后再可靠地进行异步输出。它是 EDA 事件驱动架构的核心，也是 CQRS 同步数据的关键。为什么选择 RabbitMQ 而没有选择 Kafka，因为业务系统有对消息的高可靠性要求，以及对复杂功能如消息确认 Ack 的要求。
集中式日志ELK
日志主要分为系统日志和应用日志两类。试想一下，你该如何在一个具有几百台服务器的集群中定位到问题？如何追踪每天产生的几 G 甚至几 T 的数据？集中式日志就是此类问题的解决方案。
早期我们使用自主研发的 Log4Net+MongoDB 来收集和检索日志信息，但随着数据量的增加，查询速度却变得越来越慢。后期改为开源的 ELK，虽然易用性有所下降，但它支持海量数据以及与编程语言无关的特征。下面是 ELK 的架构图。
任务调度 Job
任务调度 Job 如同数据库作业或 Windows 计划任务，是分布式系统中异步和批处理的关键。我们的 Job 分为 WinJob 和 HttpJob：WinJob 是操作系统级别的定时任务，使用开源的框架 Quartz.NET 实现；而 HttpJob 则是自主研发实现，采用 URL 方式可定时调用微服务。
HttpJob 借助集群巧妙地解决了 WinJob 的单点和发布问题，并集中管理所有的调度规则，调度规则有简单规则和 Cron 表达式。HttpJob 它简单易用，但间隔时间不能低于 1 分钟，毕竟通过 URL 方式来调度并不高效。下图是 HttpJob 的管理后台。
应用监控 Metrics
“没有度量就没有提升”，度量是改进优化的基础，是做好一个系统的前置条件。Zabbix 一般用于系统级别的监控，Metrics 则用于业务应用级别的监控。
业务应用是个黑盒子，通过数据埋点来收集应用的实时状态，然后展示在大屏或看板上。它是报警系统和数字化管理的基础，还可以结合集中式日志来快速定位和查找问题。我们的业务监控系统使用 Metrics.NET+InfluxDB+Grafana。
微服务框架 MSA
微服务是细粒度业务行为的重用，需要与业务能力及业务阶段相匹配。微服务框架是实现微服务及分布式架构的关键组件，我们的微服务框架是基于开源 ServiceStack 来实现。
它简单易用、性能好，文档自动生成、方便调试测试，调试工具 Swagger UI、自动化接口测试工具 SoapUI。微服务的接口开放采用我们自主研发的微服务网关，通过治理后台简单的配置即可。网关以 NIO、IOCP 的方式实现高并发，主要功能有鉴权、超时、限流、熔断、监控等，下图是 Swagger UI 调试工具。
搜索利器 Solr
分库分表后的关联查询，大段文本的模糊查询，这些要如何实现呢？显然传统的数据库没有很好的解决办法，这时可以借助专业的检索工具。
全文检索工具 Solr 不仅简单易用性能好，而且支持海量数据高并发，只需实现系统两边数据的准实时或定时同步即可。下图是 Solr 的工作原理。
更多工具
-
分布式协调器 ZooKeeper
ZK 工作原理、配置中心、Master 选举、Demo，一篇足以。
-
ORM 框架
Dapper.NET 语法简单、运行速度快，与数据库无关，SQL 自主编写可控，是一款适合于互联网系统的数据库访问工具。
-
对象映射工具 EmitMapper 和 AutoMapper
EmitMapper 性能较高，AutoMapper 易用性较好。
-
IoC 框架
控制反转 IoC 轻量级框架 Autofac。
-
DLL 包管理
公司内部 DLL 包管理工具 NuGet，可解决 DLL 集中存储、更新、引用、依赖问题。
-
发布工具 Jenkins
一键编译、发布、自动化测试、一键回滚，高效便捷故障低。
架构篇——思想提升
会使用以上框架并不一定能成为优秀的架构师，但一位优秀架构师一定会使用框架。架构师除了会使用工具外，还需要设计思想的提升和性能调优技能。
此篇以真实项目为背景，思想方法追求简单有效，主要内容包括 企业总体架构、单个项目架构设计、统一应用分层、调试工具 WinDbg。
企业总体架构
当我们有了几百个上千个应用后，不仅仅需要单个项目的架构设计，还需要企业总体架构做顶层思考和指导。大公司与小商贩的商业思维是一样的，但大公司比较难看到商业全貌和本质。而小公司又缺乏客户流量和中间件的应用场景，中型公司则兼而有之，所以企业总体架构也相对好落地。
企业总体架构需要在 技术、业务、管理 之间游刃有余地切换，它包括业务架构、应用架构、数据架构和技术架构。附档是一份脱敏感信息后的真实案例，有参考 TOGAF 标准。但内容以解决公司系统的架构问题为导向、以时间为主线，包括企业商务模型、架构现状、架构规划和架构实施。
单个项目架构设计
单个项目的架构设计如同施工图纸，能直接指导工程代码的实施。上一环是功能需求，下一环是代码实施，这是架构设计的价值所在。从功能需求到用例，到用例活动图，到领域图、架构分层，到核心代码，它们之间环环相扣。
做不好领域图可能源自没有做好用例活动图，因为用例活动图是领域图的上一环。关注职责、边界、应用关系、存储、部署是架构设计的核心，下图是具体案例参考。
统一应用分层
给应用分层这件事情很简单，但是让一家公司的几百个应用采用统一的分层结构，这可不是件简单的事情。它要做到可大可小、简单易用、支持多种场景，我们使用 IPO 方式：I 表示 Input、O 表示 Output、P 表示 Process，一进一出一处理。应用系统的本质就是机器，是处理设备，也是一进一出一处理，IPO 方式相对于 DDD 而言更为简单实用。
调试工具 WinDbg
生产环境偶尔会出现一些异常问题，而 WinDbg 或 GDB 就是解决此类问题的利器。调试工具 WinDbg 如同医生的听诊器，是系统生病时做问题诊断的逆向分析工具，Dump 文件类似于飞机的黑匣子，记录着生产环境程序运行的状态。
主要介绍调试工具 WinDbg 和抓包工具 ProcDump 的使用，并分享一个真实的案例。N 年前不知谁写的代码，导致每一两个月偶尔出现 CPU 飙高的现象。
我们先使用 ProcDump 在生产环境中抓取异常进程的 Dump 文件，然后在不了解代码的情况下通过 WinDbg 命令进行分析，最终定位到有问题的那行代码。
公共应用篇
先工具再框架，然后架构设计，最后深入公共应用。公共应用因为与业务系统结合紧密，但又具有一定的独立性，所以一般自主开发，不使用开源也不方便开源。公共应用主要包括单点登录、企业支付网关、CTI 通讯网关（短信邮件微信），此次分享单点登录和企业支付网关。
单点登录
应用拆分后总要合在一起，拆分是应用实施层面的拆分，合成是用户层面的合成，而合成必须解决认证和导航问题。单点登录 SSO 即只需要登录一次，便可到处访问，它是建立在用户系统、权限系统、认证系统和企业门户的基础上。我们的凭证数据 Token 使用 JWT 标准，以解决不同语言、不同客户端、跨 WebAPI 的安全问题。
企业支付网关
企业支付网关集中和封装了公司的各大支付，例如支付宝、财付通、微信、预付款等。它统一了业务系统调用各支付接口的方式，简化了业务系统与支付系统的交互。
它将各种支付接口统一为支付、代扣、分润、退款、退分润、补差、转账、冻结、解冻、预付款等，调用时只需选择支付类型即可。企业支付网关将各大支付系统进行集中的设计、研发、部署、监控、维护，提供统一的加解密、序列化、日志记录，安全隔离。
本系列文章涉及内容清单如下（并不按这顺序发布），其中有感兴趣的，欢迎关注：
-
开篇
-
缓存 Redis
-
消息队列 RabbitMQ
-
集中式日志 ELK
-
任务调度 Job
-
应用监控 Metrics
-
微服务框架 MSA
-
搜索利器 Solr
-
分布式协调器 ZooKeeper
-
小工具：Dapper.NET/EmitMapper/AutoMapper/Autofac/NuGet
-
发布工具 Jenkins
-
总体架构设计
-
单个项目架构设计
-
统一应用分层
-
调试工具 WinDbg
-
单点登录
-
企业支付网关
-
结篇
-
中小研发团队架构实践之系列大纲
以下是中小研发团队架构实践系列的大纲，部分已链接，未链接部分我也会持续的更新和发布，期待你的支持与互动。 第一篇开篇——照着做，你也能成为架构师第1章中小研发团队架构实践，附案例和代码 一、框架篇... 查看详情
从技术体系到商业洞察，中小研发团队架构实践之收尾篇
本篇主要讲从技术体系到商业洞察，分为五个小节，新一代开发范式云原生、建立自己的技术体系、技术判断力、技术业务产业周期，技术与商业洞察。对于新一代开发范式和技术体系的建立，文字部分我就不再补充，具体可以... 查看详情
一个可供中小团队参考的微服务架构技术栈
一个可供中小团队参考的微服务架构技术栈聊聊架构 2018-05-07作者 杨波作者| 杨波编辑| 张浩近年，SpringCloud俨然已经成为微服务开发的主流技术栈，在国内开发者社区非常火爆。我近年一直在一线互联网公司（携... 查看详情
百人研发团队百亿销售规模的技术架构实践分享
百人研发团队百亿销售规模的技术架构实践分享公司背景公司融资10亿,剥离B2B生鲜业务板块为独立公司运营。除部分核心产品经理，运营，采购角色外，诸如研发团队等重新组建，并承接部分历史系统重新打造一整套供应链平台... 查看详情
携程移动端架构演进与优化之路
...级以及代码级热修复，并 且逐步推动数百人的客户端研发团队由不堪重负、效率低下的大版本 查看详情
架构师多如过江之鲫，但你真的了解架构师这个工种吗（转自炼数成金）
...职业生涯经历过几次不同的架构师岗位，也组建过架构师团队。但是，当我要将其落到纸面上时，却发现今天我所看到的在行业内的架构师实在是千差万别，甚至鱼龙混杂，在方向、技 查看详情
架构设计实践
...决定，可能是架构师提出最初文档，然后经过了团队 查看详情
1.携程架构实践---携程整体技术架构(代码片段)
第1章携程整体技术架构 架构的意义在于确定"主绳"的位置。架构实际代表的是一个方法论，这个方法论的核心思想在于构建目标的主要环节，主要环节一方面可以带动次要环节，另外一方面还可以对次要环节的... 查看详情
一线架构师第三部分——细化架构
架构师的工作是领导团队的开发，但很多情况下，架构师是坐镇帷帐之中而决胜千里之外的，拥有千里的运筹能力或许就是能让项目团队一路走向成功的重要因素。对于架构师来说需求分析、分割层次、对象建模这些都是他... 查看详情
4.携程架构实践---呼叫中心(代码片段)
...叫中心 xc的呼叫中心已经演进到了第五代，即xc自主研发的基于FreeSWITCH的软交换系统，交互式语音应答系统，微信Server，邮件系统，无线IMServer的全渠道，全媒体客服云系统。 1.多渠道 2.多地域 3.多业务 4.... 查看详情
携程第四代架构探秘之运维基础架构升级
...产品及服务。2014年底携程技术中心的框架、系统和运维团队共同启动了架构改造项目，历时2年，涉及所有业务线。本文回顾了携程在整个技术架构改造过程中的一些实践和收获。一、写在前面随着携程业务量迅速增长、业务变... 查看详情
成为架构师课程系列架构设计中的核心思维方法
...技术体系进行架构和设计。#一、抽象思维如果要问软件研发/系统架构中最重要的能力是什么，我会毫不犹豫回答是抽象能力。抽象(abstraction)这个词大家经常听到，但是真正理解和能讲清楚什么是抽象的人少之又少。抽象其实是... 查看详情
求贤若渴（java架构师技术专家）
...多活等复杂架构规划及落地，负责阿里巴巴MySQL内核研发，研发了OceanBase、数据管理DMS、数据传输DTS云计算产品。我们的 查看详情
怎样成为一个优秀的架构师？
...构的设计。IT架构师-软件产品架构师：专注于软件产品的研发。IT架构师-应用架构师：专注于结合企业需求，定制化IT解决方案；大部分需要交付的工作包括总体架构、应用架构、数据架构，甚至部署架构。IT架构师-技术架构师... 查看详情
研发中台拆分过程的一些心得总结
...xff0c;前期从企业上云，再到DevOps，技术中台，研发中台还有业务中台的建设，中台原带有的架构设计概念，更偏向于企业可复用的组件，多个业务线共用的服务，结合主流的微服务技术，包括dubbo/cl... 查看详情
架构师的责任（架构师的成长之路---第3篇）
...，多学习，跟随最新技术，不断地升华自己，并不停的为团队传输最新知识，让整个团队不断地进步。 难点攻克是指架构师要有逢山开路，遇水搭桥的能力。当团队遇到开发难题的时候，架构师永远是团队最后的堡垒，... 查看详情
架构实践架构师必知必会的5种业界主流的架构风格
【架构实践】架构师必知必会的5种业界主流的架构风格目录 【架构实践】架构师必知必会的5种业界主流的架构风格 查看详情
架构实践架构师必知必会的5种业界主流的架构风格
【架构实践】架构师必知必会的5种业界主流的架构风格目录 【架构实践】架构师必知必会的5种业界主流的架构风格 查看详情