“ 任何人写的代码，终究要在生产环境上运行。”





01 时刻以生产环境为本



我们写的代码，终究是要在生产环境上跑的。生产环境和我们平时面对的开发环境、测试环境可不一样。生产环境上的系统必须维持业务的连续性。



要做到这一点，我们必须要避免单点故障。也就是说，系统服务不能因为某台服务器、某个中间件等出现故障而中断。



系统也必须要有容灾设计，当主机房出现全面故障时，系统服务也能切换到其他机房，继续提供服务。平时也要定期进行切换演练。



系统还必须要有各种的监控和预警，在出现故障时让我们掌握先机，及时处理，避免或减少用户或业务的影响或损失。



为了应对随时变化的访问量，系统必须有一定的弹性。在访问高峰时顶得住，在访问低谷时能节省资源，从而节省成本。



另外，性能、安全等的非功能性需求都要一一满足。



要做到以上要求，我们在做软件设计时，就要以终为始，必须考虑到以上要求和系统在生产环境上运行时的各种情况。这些问题有些需要在软件设计、代码上处理，有些需要通过架构设计来处理，甚至需要代码和架构协同处理。



懂点系统架构，就能帮助我们在软件搭建初期把这些因素考虑在内。软件虽然是可变的，但变更越晚，成本越高，风险也越高。所以最好把这个过程提前。



应对前面提到的要求，我们在做系统设计、架构设计起码需要做到：



• 避免单点故障



有两种方案：



1. 故障转移（Failover）——把系统部署到两台服务器，其中一台服务器是主服务器，所有用户请求默认发到这台服务器；另一台服务器是备用服务器。一旦主服务器出现故障，所有用户请求切换到备用服务器，继续提供服务，为修复主服务器故障争取时间。

2. 双活或多活（onsite resilience）——把系统部署到两台服务器，并把用户的请求均衡地分配给这两台服务器分别处理，那么不光系统的处理能力提升了，而且即使其中一台服务器出现故障，另一台服务器依然可以支撑服务，处理用户请求，这种设计叫“双活”。如果是通过多台服务器来实现这种设计，就叫“多活”。“双活”或“多活”的实现，往往需要代码和架构协同。



• 容灾设计



以上是从服务器的角度来考虑的。放置服务器的机房也会出现故障，比如当地震、海啸、水灾、火灾、断电、雷击等灾难发生时，可能会出现整个机房无法工作的情况，从而导致企业的所有IT系统无法提供服务。要避免这种情况，很多企业都会建设灾备机房，这也是监管机构对某些行业的硬性要求。对于灾备机房，一般要求“同城异地”，也就是主机房和灾备机房在同一城市的不同地点，需要有一定的物理距离。更高的要求有“两地三中心”，也就是在“同城异地”的基础上，还需要在另外一座城市配置一个机房。



• 监控和预警



监控可以是以下多个层次和维度的：



1. 用户体验（系统是否能对用户访问提供及时响应）；

2. 业务流量（业务流量增长情况，是否有突发流量）；

3. 系统状态（系统运行状态是否满足设计时的各项指标）；

4. 中间件状态（数据库、MQ、Radis等的中间件是否有异常，流量情况）；

5. 服务器状态（CPU、内存、磁盘、网络等的情况）。



02 架构重构是一种武器



随着业务变得复杂，业务量上升，系统应对的场景也愈发复杂。应对这些复杂问题，除了系统代码的不断调整与优化、敏捷与DevOps这样的工程学上的改进外，架构重构也是重要的武器。



一个高度耦合的系统，变更难度和风险都大，变更周期必然被拉长，无法适应在瞬息万变的市场中快速交付的需要。



要真正实现敏捷与DevOps的倡导的持续交付，没有架构设计上的支持，也是无法实现的。



架构重构，是其中一种解耦的手段。解耦，是把系统以相对独立、完整的功能、模块或服务进行拆解，从而使这些功能、模块、服务可以相对独立地进行开发和维护，减少彼此的依赖，加快交付速度，减少交付风险。



通过架构重构对系统进行服务化改造，使各核心服务形成独立的架构和系统。团队的组织架构，也可以根据新的系统架构进行调整，每个团队独立负责一个服务，从而实现“自给自足”，减少对外依赖和摩擦。



近年来流行的微服务架构，其实就是通过架构手段的终极解耦方案。



应对业务量的持续上升这个“好问题”（Good Problem），架构手段提供了更丰富的抓手。以下是一些例子：



1. 横向扩容——单靠提高服务器的配置成本高，也有极限。通过部署多台服务器的横向扩容，弹性更好，云更是为横向扩容而生的赋能者。

2. 异步通讯——通过异步通讯，可以实现横向扩容后多个数据节点间的数据可靠同步，也可以实现在高并发的场景下，一些非实时服务的延后处理，从而缓解核心的、需要实时响应的服务的压力。比如购物场景下的积分登记服务，如果不需要实时性，可以由支付服务向消息队列发送消息让积分服务异步处理。

3. 读写分离——大多数场景下，对数据读的需求比写要大。大多数数据库已提供了多台服务器数据同步的功能，通过读写分离，可以把写操作集中在一台数据库服务器，最新数据会通过同步机制更新到其他横向扩容的数据库服务器，读操作可以分散在这些扩容服务器，从而大大提升系统的处理能力。读写分离需要代码与架构协同实现。



有些这些系统架构的思路，当我们应对复杂的业务场景、突发的流量时，便有了更多的灵感。



03 架构思维是一种全局观



由于系统架构是系统的骨骼，也是系统运行的全景视图，这必然要求我们以全局的思维看待系统。从架构层面思考问题，既需要我们对业务有深入的理解，也需要我们对系统有深入的洞察。



这里并不是要求人人都成为架构师，而是不管你在从事软件交付的任何角色，架构思维都是一种很好的全局思维。避免我们闭门造车和盲人摸象。



以生产环境为本的思维，也能帮助我们以终为始，避免只关注局部和细节的迷思。



我在《高级人才的价值在于管理复杂性的能力》提到过，一个优秀的架构师需要以下能力：





1. Technical Excellence 技术牛 - 这个不用多说；

2. Communication Mastery 沟通达人 - 架构设计绝对不是画张图那么简单，你需要和不同技术团队进行深入交流，才能做出切实可行的架构方案；

3. Leadership Power 领导力 - 同理，只要需要协作，就需要领导力。你的图纸，别人不买账，就是废纸一张。

我想这些能力也是每个软件人所必须具备的。



04 总结



任何人写的代码，终究要在生产环境上运行。生产环境要保持业务的连续性，需要避免单点故障，具备弹性、容灾等的能力。应对业务的复杂性、持续增长和突发流量，系统需要不断解耦和扩容。系统架构是应对这些场景的重要武器，也让我们对业务、系统具有更好的全局观。所以，所有软件人都应该懂点系统架构。





近期必读：



很不幸，自动化测试永远只能是必要非充分条件



高级人才的价值在于管理复杂性的能力



面对疫情这样的复杂问题，有什么招呢？



关于作者



刘华（Kenneth）



• 就职于世界500强银行，负责基金服务业务软件开发与交付

• 敏捷、精益、DevOps专家

• 精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈

• 曾在GDevOps、DevOpsDays Meetup、中国软件技术大会、ArchSummit等论坛发表主题演讲

• 著有《猎豹行动：硝烟中的敏捷转型之旅》一书



小说体敏捷/DevOps转型教科书和实战经验分享



购书指南



纸质书、电子书在京东、当当、亚马逊、微信读书等渠道已全面上架，搜索关键字“猎豹 敏捷”即可找到。有声书已登录喜马拉雅、微信读书，适合路上听书的你。