团队架构实践
中小研发团队架构实践之开篇
成本低，可快速搭建的中间件及架构升级方案呢？我是一个有十多年经验的IT老兵，曾主导了两家公司的技术架构升级改造，现抛砖引玉，与大家一起探讨这方面的问题。整个系列有18篇文章，可分为三个部分，包括框架篇、架构篇和公共应用篇。框架篇即中间件或工具的使用，如缓存、消息队列、集中式日志、度量、微服务框架等，工欲善其事，必先利其器。架构篇主要是设计思想的提升，有企业总体架构、单个项目架构设计、统一应用分层等。公共应用篇是业务与技术的结合，有单点登录和企业支付网关，以下是具体篇章的介绍：
一、框架篇——工欲善其事，必先利其器
如果说运维是地基，那么框架就是承重墙。农村建住房是一块砖一块砖地往上垒，而城市建大House则是先打地基，再建承重墙，最后才是垒砖，所以中间件的搭建和引进是建设高可用、高性能、易扩展可伸缩的大中型系统的前提。框架篇中的每篇主要由四部分组成：它是什么、工作原理、使用场景和可直接调试的Demo。其中Demo及中间件是历经两家公司四年时间的考验，涉及几百个应用，100多个库1万多张表，日订单从几万张到十几万，年GMV从几十亿到几百亿。所有中间件及工具都是基于开源，早期我们也有部分自主研发如集中式日志和度量框架。后期在第二家公司时为了快速地搭建，降低成本，易于维护和扩展，全部改为开源。这样不仅利于个人的学习成长、知识重用和职业生涯，也利于团队的组建和人才的引进。
1、集中式缓存Redis
Lua计算能力、Limit与Session时间窗口、分布式锁等。我们使用ServiceStack.Redis做客户端，使用方法详见Demo。
2、消息队列RabbitMQ
消息队列好比葛洲坝，有大量数据的堆积能力，然后再可靠地进行异步输出。它是EDA事件驱动架构的核心，也是CQRS同步数据的关键。为什么选择RabbitMQ而没有选择Kafka，因为业务系统有对消息的高可靠性要求，以及对复杂功能如消息确认Ack的要求。
3、集中式日志ELK
日志主要分为系统日志和应用日志两类。试想一下，你该如何在一个具有几百台服务器的集群中定位到问题？如何追踪每天产生的几G甚至几T的数据？集中式日志就是此类问题的解决方案。早期我们使用自主研发的Log4Net+MongoDB来收集和检索日志信息，但随着数据量的增加，查询速度却变得越来越慢。后期改为开源的ELK，虽然易用性有所下降，但它支持海量数据以及与编程语言无关的特征。下图是ELK的架构图。
4、任务调度Job
。下图是HttpJob的管理后台。
5、应用监控Metrics
中式日志来快速定位和查找问题。我们的业务监控系统使用Metrics.NET+InfluxDB+Grafana。
6、微服务框架MSA
调试工具。
7、搜索利器Solr
定时同步即可。下图是Solr的工作原理。
8、更多工具
二、架构篇——思想提升
会使用以上框架并不一定能成为优秀的架构师，但一位优秀架构师一定会使用框架。架构师除了会使用工具外，还需要设计思想的提升和性能调优技能。此篇以真实项目为背景，思想方法追求简单有效，主要内容包括企业总体架构、单个项目架构设计、统一应用分层、调试工具WinDbg。
1、企业总体架构
标准。但内容以解决公司系统的架构问题为导向、以时间为主线，包括企业商务模型、架构现状、架构规划和架构实施。
2、单个项目架构设计
做不好领域图可能源自没有做好用例活动图，因为用例活动图是领域图的上一环。关注职责、边界、应用关系、存储、部署是架构设计的核心，下图是具体案例参考。
3、统一应用分层
IPO方式相对于DDD而言更为简单实用。
4、调试工具WinDbg
工具，Dump文件类似于飞机的黑匣子，记录着生产环境程序运行的状态。本文主要介绍了调试工具WinDbg和抓包工具ProcDump的使用，并分享一个真实的案例。N年前不知谁写的代码，导致每一两个月偶尔出现CPU飙高的现象。我们先使用ProcDump在生产环境中抓取异常进程的Dump文件，然后在不了解代码的情况下通过WinDbg命令进行分析，最终定位到有问题的那行代码。
——业务与技术的结合
先工具再框架，然后架构设计，最后深入公共应用。这不仅是架构升级改造的正确路径，也是微服务架构实施的正确路径。公共应用因为与业务系统结合紧密，但又具有一定的独立性，所以一般自主开发，不使用开源也不方便开源。公共应用主要包括单点登录、企业支付网关、CTI通讯网关（短信邮件微信），此次分享单点登录和企业支付网关。
1、单点登录
凭证数据Token使用JWT标准，以解决不同语言、不同客户端、跨WebAPI的安全问题。
2、企业支付网关
企业支付网关集中和封装了公司的各大支付，例如支付宝、财付通、微信、预付款等。它统一了业务系统调用各支付接口的方式，简化了业务系统与支付系统的交互。它将各种支付接口统一为支付、代扣、分润、退款、退分润、补差、转账、冻结、解冻、预付款等，调用时只需选择支付类型即可。企业支付网关将各大支付系统进行集中的设计、研发、部署、监控、维护，提供统一的加解密、序列化、日志记录，安全隔离。
在接下来的一段时间里，我会陆续推出此系列文章。因个人原因，发布顺序会根据本人的准备情况而作调整，敬请谅解。根据我们以往的经验，分享者主讲一个小时左右，业务研发就可以快速地进入项目实战。对于后面新加入的团队成员，也可通过WIKI自主快速学习。这是我们之前对自己的要求，尽量降低工具对人员的要求，简单实用、降低成本。文章中部分Demo采用C#语言，但到了框架或架构层面，与语言本身没有太多直接的关系。如RabbitMQ、Job、Redis和集中式日志ELK，它们服务端的部署是一样的，只是客户端语言版本稍有不同。所有Demo都可直接运行，服务地址及管理后台也可直接访问。因为部署在公有云，牵涉到成本费用的问题，我计划持续到明年3月底。以上这些小小的基础工作，希望能够帮到中小型研发团队，解决他们项目中遇到的实际问题。愿与你一起成长，你的分享和点赞是我此次付出的动力，谢谢！
成本低，可快速搭建的中间件及架构升级方案呢？我是一个有十多年经验的IT老兵，曾主导了两家公司的技术架构升级改造，现抛砖引玉，与大家一起探讨这方面的问题。整个系列有18篇文章，可分为三个部分，包括框架篇、架构篇和公共应用篇。框架篇即中间件或工具的使用，如缓存、消息队列、集中式日志、度量、微服务框架等，工欲善其事，必先利其器。架构篇主要是设计思想的提升，有企业总体架构、单个项目架构设计、统一应用分层等。公共应用篇是业务与技术的结合，有单点登录和企业支付网关，以下是具体篇章的介绍：
一、框架篇——工欲善其事，必先利其器
如果说运维是地基，那么框架就是承重墙。农村建住房是一块砖一块砖地往上垒，而城市建大House则是先打地基，再建承重墙，最后才是垒砖，所以中间件的搭建和引进是建设高可用、高性能、易扩展可伸缩的大中型系统的前提。框架篇中的每篇主要由四部分组成：它是什么、工作原理、使用场景和可直接调试的Demo。其中Demo及中间件是历经两家公司四年时间的考验，涉及几百个应用，100多个库1万多张表，日订单从几万张到十几万，年GMV从几十亿到几百亿。所有中间件及工具都是基于开源，早期我们也有部分自主研发如集中式日志和度量框架。后期在第二家公司时为了快速地搭建，降低成本，易于维护和扩展，全部改为开源。这样不仅利于个人的学习成长、知识重用和职业生涯，也利于团队的组建和人才的引进。
1、集中式缓存Redis
Lua计算能力、Limit与Session时间窗口、分布式锁等。我们使用ServiceStack.Redis做客户端，使用方法详见Demo。
2、消息队列RabbitMQ
消息队列好比葛洲坝，有大量数据的堆积能力，然后再可靠地进行异步输出。它是EDA事件驱动架构的核心，也是CQRS同步数据的关键。为什么选择RabbitMQ而没有选择Kafka，因为业务系统有对消息的高可靠性要求，以及对复杂功能如消息确认Ack的要求。
3、集中式日志ELK
日志主要分为系统日志和应用日志两类。试想一下，你该如何在一个具有几百台服务器的集群中定位到问题？如何追踪每天产生的几G甚至几T的数据？集中式日志就是此类问题的解决方案。早期我们使用自主研发的Log4Net+MongoDB来收集和检索日志信息，但随着数据量的增加，查询速度却变得越来越慢。后期改为开源的ELK，虽然易用性有所下降，但它支持海量数据以及与编程语言无关的特征。下图是ELK的架构图。
4、任务调度Job
。下图是HttpJob的管理后台。
5、应用监控Metrics
中式日志来快速定位和查找问题。我们的业务监控系统使用Metrics.NET+InfluxDB+Grafana。
6、微服务框架MSA
调试工具。
7、搜索利器Solr
定时同步即可。下图是Solr的工作原理。
8、更多工具
二、架构篇——思想提升
会使用以上框架并不一定能成为优秀的架构师，但一位优秀架构师一定会使用框架。架构师除了会使用工具外，还需要设计思想的提升和性能调优技能。此篇以真实项目为背景，思想方法追求简单有效，主要内容包括企业总体架构、单个项目架构设计、统一应用分层、调试工具WinDbg。
1、企业总体架构
标准。但内容以解决公司系统的架构问题为导向、以时间为主线，包括企业商务模型、架构现状、架构规划和架构实施。
2、单个项目架构设计
做不好领域图可能源自没有做好用例活动图，因为用例活动图是领域图的上一环。关注职责、边界、应用关系、存储、部署是架构设计的核心，下图是具体案例参考。
3、统一应用分层
IPO方式相对于DDD而言更为简单实用。
4、调试工具WinDbg
工具，Dump文件类似于飞机的黑匣子，记录着生产环境程序运行的状态。本文主要介绍了调试工具WinDbg和抓包工具ProcDump的使用，并分享一个真实的案例。N年前不知谁写的代码，导致每一两个月偶尔出现CPU飙高的现象。我们先使用ProcDump在生产环境中抓取异常进程的Dump文件，然后在不了解代码的情况下通过WinDbg命令进行分析，最终定位到有问题的那行代码。
——业务与技术的结合
先工具再框架，然后架构设计，最后深入公共应用。这不仅是架构升级改造的正确路径，也是微服务架构实施的正确路径。公共应用因为与业务系统结合紧密，但又具有一定的独立性，所以一般自主开发，不使用开源也不方便开源。公共应用主要包括单点登录、企业支付网关、CTI通讯网关（短信邮件微信），此次分享单点登录和企业支付网关。
1、单点登录
凭证数据Token使用JWT标准，以解决不同语言、不同客户端、跨WebAPI的安全问题。
2、企业支付网关
企业支付网关集中和封装了公司的各大支付，例如支付宝、财付通、微信、预付款等。它统一了业务系统调用各支付接口的方式，简化了业务系统与支付系统的交互。它将各种支付接口统一为支付、代扣、分润、退款、退分润、补差、转账、冻结、解冻、预付款等，调用时只需选择支付类型即可。企业支付网关将各大支付系统进行集中的设计、研发、部署、监控、维护，提供统一的加解密、序列化、日志记录，安全隔离。
在接下来的一段时间里，我会陆续推出此系列文章。因个人原因，发布顺序会根据本人的准备情况而作调整，敬请谅解。根据我们以往的经验，分享者主讲一个小时左右，业务研发就可以快速地进入项目实战。对于后面新加入的团队成员，也可通过WIKI自主快速学习。这是我们之前对自己的要求，尽量降低工具对人员的要求，简单实用、降低成本。文章中部分Demo采用C#语言，但到了框架或架构层面，与语言本身没有太多直接的关系。如RabbitMQ、Job、Redis和集中式日志ELK，它们服务端的部署是一样的，只是客户端语言版本稍有不同。所有Demo都可直接运行，服务地址及管理后台也可直接访问。因为部署在公有云，牵涉到成本费用的问题，我计划持续到明年3月底。以上这些小小的基础工作，希望能够帮到中小型研发团队，解决他们项目中遇到的实际问题。愿与你一起成长，你的分享和点赞是我此次付出的动力，谢谢！