张亮
/
当当架构部总监
主要负责分布式中间件以及私有云平台的搭建。致力于开源，目前主导两个开源项目elastic-job和sharding-jdbc。擅长以Java为主的分布式架构和以Mesos为主的云平台方向，推崇优雅代码，对如何写出具有展现力的代码有较多研究。
以下内容为活动实录：
对于一个做技术的从业人员来说，大部分人开始走的是一条技术+业务的线路。从业务功能回顾一下工程师的工作的大致内容：
通过解读需求文档，理解并分析业务。
将对业务的理解抽象和归纳为领域模型，并通过绘制UML展现。
大部分应用程序都是有数据库的。在设计过程中，有人喜欢先设计数据库表结构，再创建域模型，也可以反过来，习惯而已。
在表结构设计完毕之后，就会选择或搭建合适的开发框架，然后进入开发阶段。基础框架采用分层模型居多，选用ssh或ssi等流行的框架比较常见。
随着经验越来越丰富，工程师的关注点从功能需求逐渐扩展到了非功能需求。功能的满足只是冰山浮在水面上的一小块；而冰山下面的的巨大沉积物则是非功能需求，它们经常被非技术从业人员所忽视，但却是实实在在地影响一个系统成功与否的关键。
有无SQL注入和跨域脚本攻击的问题；密码是否明文在网络间传输；是否可通过主键推算出其他主键并达到非法访问的目的（如：ID是连续的，只要知道一个ID，就可能获取到其他人的信息）。
程序会否由于异常情况导致崩溃，性能是否稳定（如：锁的不正确使用导致等待过多）等。
业务成长初期和业务爆发性增长期的应用承载量是完全不同的。当业务快速增长，应用承载量大幅度提升时，如何通过增加服务器数量的水平扩展而不是增加单一服务器硬件配置的垂直扩展来达到承载更多流量和数据量的目的，并且可以在流量洪峰平稳度过后适当的减少硬件服务器来控制成本。
在需要人工介入的系统部署流程中，失误难于完全避免。并且由于网络抖动而需要运维或重启时，大量的手工操作难免手忙脚乱，极易产生操作延迟。应通过自动化调度以及部署来帮助运维工程师尽量降低人工介入的频度。
在成长的轨迹中，工程师大多从微观入手，并最终领悟如何从宏观看待技术。
几个常见的微观关注点：
相信工程师们应该都做过这件事，分析SQL执行计划，查看索引命中情况等。
单线程时没有问题，但多线程时则可能产生莫名其妙的问题。如何在多线程中合理的使用synchronized，volatile以及并发包等，是重要且困难的。并不是不写多线程代码就能完全规避这些问题。若使用的框架包括多线程，也需要使用者理解它的线程模型。
一个跑在JVM里面的程序，如果每小时做一次Full GC导致应用停止响应一秒的时间，在性能以及并发要求较高的系统中是难以接受的。需要通过JVM调优来降低Full GC频度。
设计模式是发现而非发明出来的，目前设计模式已经归纳的很成熟了，已不太容易再发现新设计模式。利用设计模式可以更好的写出结构清晰，易于理解的代码，并降低相互的沟通成本。
若代码本身难以理解，即使通过注释也难于让代码本身具有表现力。而且代码和注释也不一定是同步修改的。着急改代码，但注释没有改的情况比较常见，这样的注释是没有价值的，不如花些时间让代码本身更具展现力。
随着时间的推移以及经验的累积，工程师会渐渐地关注更加宏观的方面，例如：
存储订单、交易等核心数据，稳定成熟的关系型数据库是不二之选；存储帖子类的文本数据， ES就会更加合适。因此需要工程师了解各种数据库的适合场景，结合上下文分析并最终确定选型。
规模较大公司的系统不可能仅有一个或几个，它们也不会将所有的服务全部部署在同一个应用服务器中，而是将其拆分为几十、几百甚至上千个系统。无论是当前较为流行的微服务架构，还是以前提及较多的SOA架构，都需要对系统进行拆分。如何合理划分系统的范围是宏观思考的范畴，如：一个需求应该放入哪个系统，多个需求是否是独立组成的新系统等。
系统增多，则需要考虑系统间的通信交互方式。通信有RPC或RESTful的同步访问方式，也有通过消息中间件的异步访问方式。定义各种交互的规范，如：确定采用同步通信以及异步通信的标准；确定采用明文、二进制以及加密自定义序列化协议的场景。
分布式系统和单机系统最大的区别在于分布式的不确定性，每次远程调用的请求是否到达难于保证。单机系统宕机，会导致整个系统不可用，但尽力去维护一个单一的系统难度并不大。而分布式系统出现最多的场景是一部分服务宕机，其余的大部分服务仍然正常。在系统很多的情况下，其排列组合的可能性是指数级上升的。如何能在这种情况下，保证系统的可用性以及伸缩性，是需要从宏观点考虑的。如：是否需要有服务治理系统，如何监控，何时扩容等。
在容器、云计算发展的较为成熟的今天，基于Mesos、K8S、Swarm等平台提供资源分配 +调度+部署的一体化平台已不是难事。比如，现在有一个由2台4核服务器组成的8核小集群，运行一个任务只占用0.5核CPU，如果该任务占用整个一台服务器，资源利用率是很低的，因此需要考虑资源的合理分配和调度。一旦某台服务器宕机，应将该服务器中运行的任务分配到另一台服务器中，这个过程应尽量自动化。
以上简单了聊了一些技术人员随着经验和技能的增长的客观变化。工作内容会从仅关心业务功能转变为同时关注非功能需求，思维方式也会经历的从微观到宏观的大局观演进。接下来聊一聊主观方面的东西，从工匠精神开始谈吧。
工匠精神是什么？
借用日本剑道三个字——“
守破离
”。它对其他行业也有借鉴意义，对从事技术行业的同事来说，可以这样解读：
守——
钻研基础知识、
理解经典理论、熟悉各种
轮子
首先，应充分了解技术的现状。现在的各种技术栈已经趋于完善，应该多了解、多体会、多学习，多思考。尽量多的理解经典理论，比如，CAP理论是在说明什么问题，BASE的最终一致性该怎么做；基于PAXOS和ZAB协议做的ZooKeeper适用于什么场景，Raft和他们又有什么异同；ACID的强事务又应该用在何处等。理解经典理论的同时，再熟悉各种各样的轮子。这时不应急于考虑自己应该重新做什么，如果没有熟练的使用Spring Framework，理解它的依赖注入和控制反转理念，直接做一个超越它的框架又谈何容易。
破——
尝试修改框架源码，
总结自己的
最佳
实践
通过学习钻研，已逐渐的形成自己的独立知识体系。对一些技术通用性不强，但行业通用性较强的问题，可以自己写框架，或者改写优秀框架的源码，吸收其精华，彻底转化为自己的知识。通过总结自己独特的最佳实践，慢慢的找到一条适合自己的道路，其不仅限于技术，也包括管理、做事方式等方面。
离——抛开束缚，
开辟新境界
这个境界很多人终其一生也很难达到。触摸到这个境界之时，可以将一切的束缚都抛开，根据自己的经验和能力，顺势而为的完成一些作品，独立地创造一些东西，可以是技术产品，也可以是服务，更可以是创业的公司。
概括来说，守，刚到公司，熟悉自己的工作，积累经验；破，在团队中负责核心工作，根据自己的知识制定规范，领导他人；离，可遇而不可求，创造更大的价值。举例来说， Linux、MySQL、Hadoop这种级别的产品的所谓的神级人物，他们所做的不仅仅是一个产品，而是一个时代。
技术并不简单，无论
是深度还是广度，
都
存在极大的纵深。
想
真正的
成长为大牛，应该要遵循工匠精神，产生足够敬意，因为接下来会有一条很长的路要走。
