当当网架构师：从码农到大牛，技术与心境的双重提升

《当当网架构师：从码农到大牛，技术与心境的双重提升》要点：
本文介绍了当当网架构师：从码农到大牛，技术与心境的双重提升，希望对您有用。如果有疑问，可以联系我们。

一、业务功能关注点

对于一个做技术的从业人员来说,大部分人开始走的是一条技术+业务的线路.从业务功能回顾一下工程师大致的工作内容：

1、业务理解和分析?

通过解读需求文档,理解并分析业务.

2、UML建模?

将对业务的理解抽象和归纳为领域模型,并通过绘制UML展现.

3、数据库表结构设计?

大部分应用程序都是有数据库的.在设计过程中,有人喜欢先设计数据库表结构,再创建域模型,也可以反过来,习惯而已.

4、选择合适的开发框架?

在表结构设计完毕之后,就会选择或搭建合适的开发框架,然后进入开发阶段.基础框架采用分层模型居多,选用ssh或ssi等流行的框架比较常见.

随着经验越来越丰富,工程师的关注点从功能需求逐渐扩展到了非功能需求.功能的满足只是冰山浮在水面上的一小块；而冰山下面的的巨大沉积物则是非功能需求,它们经常被非技术从业人员所忽视,但却是实实在在地影响一个系统成功与否的关键.

二、非功能需求关注点

1、安全性?

有无SQL注入和跨域脚本攻击的问题；密码是否明文在网络间传输；是否可通过主键推算出其他主键并达到非法访问的目的(如：ID是连续的,只要知道一个ID,就可能获取到其他人的信息).

2、健壮性

程序是否会由于异常情况导致崩溃,性能是否稳定(如：锁的不正确使用导致等待过多)等.

3、可伸缩性?

业务成长初期和业务爆发性增长期的应用承载量是完全不同的.当业务快速增长,应用承载量大幅度提升时,如何通过增加服务器数量的水平扩展而不是增加单一服务器硬件配置的垂直扩展来达到承载更多流量和数据量的目的,并且可以在流量洪峰平稳度过后适当的减少硬件服务器来控制成本.

4、可维护性?

在需要人工介入的系统部署流程中,失误难于完全避免.并且由于网络抖动而需要运维或重启时,大量的手工操作难免手忙脚乱,极易产生操作延迟.应通过自动化调度以及部署来帮助运维工程师尽量降低人工介入的频度.

在成长的轨迹中,工程师大多从微观入手,并最终领悟如何从宏观看待技术.

三、成长轨迹：微观关注点

几个常见的微观关注点：

1、如何对慢SQL创建索引?

相信工程师们应该都做过这件事,分析SQL执行计划,查看索引命中情况等.

2、如何保证线程安全?

单线程时没有问题,但多线程时则可能产生莫名其妙的问题.如何在多线程中合理的使用synchronized,volatile以及并发包等,是重要且困难的.并不是不写多线程代码就能完全规避这些问题.若使用的框架包括多线程,也需要使用者理解它的线程模型.

3、如何减少Full GC的频度?

一个跑在JVM里面的程序,如果每小时做一次Full GC导致应用停止响应一秒的时间,在性能以及并发要求较高的系统中是难以接受的.需要通过JVM调优来降低Full GC频度.

4、如何考虑使用设计模式?

设计模式是发现而非发明出来的,目前设计模式已经归纳得很成熟了,已不太容易再发现新设计模式.利用设计模式可以更好地写出结构清晰,易于理解的代码,并降低相互的沟通成本.

5、如何写出具备强表现力的代码?

若代码本身难以理解,即使通过注释也难于让代码本身具有表现力.而且代码和注释也不一定是同步修改的.着急改代码,但注释没有改的情况比较常见,这样的注释是没有价值的,不如花些时间让代码本身更具展现力.

四、成长轨迹：宏观关注点

随着时间的推移以及经验的累积,工程师会渐渐地关注更加宏观的方面,例如：

1、如何选用适合数据库存储相应的数据?

存储订单、交易等核心数据,稳定成熟的关系型数据库是不二之选；存储帖子类的文本数据,ES就会更加合适.因此需要工程师了解各种数据库的适合场景,结合上下文分析并最终确定选型.

2、如何规划系统范围的划分和拆分?

规模较大公司的系统不可能仅有一个或几个,它们也不会将所有的服务全部部署在同一个应用服务器中,而是将其拆分为几十、几百甚至上千个系统.无论是当前较为流行的微服务架构,还是以前提及较多的SOA架构,都需要对系统进行拆分.如何合理划分系统的范围是宏观思考的范畴,如：一个需求应该放入哪个系统,多个需求是否是独立组成的新系统等.

3、如何规范系统间的同步异步通讯方式?

系统增多,则需要考虑系统间的通信交互方式.通信有RPC或RESTful的同步访问方式,也有通过消息中间件的异步访问方式.定义各种交互的规范,如：确定采用同步通信以及异步通信的标准；确定采用明文、二进制以及加密自定义序列化协议的场景.

4、分布式系统高可用以及伸缩性如何保障?

分布式系统和单机系统最大的区别在于分布式的不确定性,每次远程调用的请求是否到达难于保证.单机系统宕机,会导致整个系统不可用,但尽力去维护一个单一的系统难度并不大.而分布式系统出现最多的场景是一部分服务宕机,其余的大部分服务仍然正常.在系统很多的情况下,其排列组合的可能性是指数级上升的.如何能在这种情况下,保证系统的可用性以及伸缩性,是需要从宏观点考虑的.如：是否需要有服务治理系统,如何监控,何时扩容等.

5、如何考虑资源、调度、运维、监控一体化?

在容器、云计算发展较为成熟的今天,基于Mesos、K8S、Swarm等平台提供资源分配?+调度+部署的一体化平台已不是难事.比如,现在有一个由2台4核服务器组成的8核小集群,运行一个任务只占用0.5核CPU,如果该任务占用整个一台服务器,资源利用率是很低的,因此需要考虑资源的合理分配和调度.一旦某台服务器宕机,应将该服务器中运行的任务分配到另一台服务器中,这个过程应尽量自动化.

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!