为什么每个软件人都要懂点系统架构?

用户头像
刘华Kenneth
关注
发布于: 2020 年 05 月 03 日
为什么每个软件人都要懂点系统架构?

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





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转型教科书和实战经验分享



购书指南



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



发布于: 2020 年 05 月 03 日 阅读数: 74
用户头像

刘华Kenneth

关注

敏捷、精益、DevOps专家 2017.10.19 加入

著有《猎豹行动:硝烟中的敏捷转型之旅》一书;敏捷、精益、DevOps专家;公众号“敏于思 捷于行”博主;曾在国内多个大型论坛发表过主题演讲;就职于世界500强银行。

评论

发布
暂无评论
为什么每个软件人都要懂点系统架构?