程序员如何蜕变成架构师
程序员更多的关注的是局部，而架构师则是全局，这个蜕变的过程，是一个长期积累的过程，是一个需要量变的过程，最后才能从量变转化为质变，成为一名合格的架构师。
一、什么是架构
- 需求相对复杂.
- 非功能性需求在整个系统占据重要位置.
- 系统生命周期长,有扩展性需求.
- 系统基于组件或者集成的需要.
- 业务流程再造的需要.
二、架构分类
- 架构可分为业务架构、应用架构、技术架构, 代码架构, 部署架构。
- 业务架构是战略，应用架构是战术，技术架构是装备。其中应用架构承上启下，一方面承接业务架构的落地，另一方面影响技术选型。
- 业务架构
- 包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。
- 没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓。
- 所有问题的前提要搞清楚我们今天面临的业务量有多大，增长走势是什么样，而且解决高并发的过程，一定是一个循序渐进逐步的过程。 合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。
2.应用架构
- 划分
1）、 职责划分: 明确应用（各个逻辑模块或者子系统）边界
a. 逻辑分层
b. 子系统、模块定义。
c. 关键类。
2）、 职责之间的协作：
a. 接口协议：应用对外输出的接口。
b. 协作关系：应用之间的调用关系。
- 应用分层有两种方式:
1）、水平分（横向），按照功能处理顺序划分应用，比如把系统分为web前端/中间服务/后台任务，这是面向业务深度的划分。
2）、垂直分（纵向），按照不同的业务类型划分应用，比如进销存系统可以划分为三个独立的应用，这是面向业务广度的划分。
总结：业务架构、应用架构、技术架构三者之间，应用架构是个承上启下的连接作用，应用架构依赖业务架构，同时又影响技术架构。
应用架构的本质是通过系统拆分，平衡业务和技术复杂性，保证系统形散神不散。
3.代码架构（也叫开发架构）
公司统一代码架构，如果不同开发团队使用不同的技术栈或者组件，结果公司整体架构设计就会失控
- 代码架构主要定义：
1）、 代码单元
a. 配置设计
b. 框架、类库
2）、 代码单元组织：
a. 编码规范，编码的惯例
b. 项目模块划分
c .顶层文件结构设计，比如mvc设计
d.依赖关系
4.技术架构
技术架构：确定组成应用系统的实际运行组件（lvs，Nginx，Tomcat，php-fpm等），这些运行组件之间的关系，以及部署到硬件的策略。
技术架构主要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。
5.部署拓扑架构
三、架构设计的3个原则
1、简单
1）组件越多，就越有可能其中某个组件出现故障
2）某个组件改动，会影响关联的所有组件
3）定位一个复杂系统中的问题总是比简单系统更加困难
总结：简单优于复杂，无论是结构的复杂性，还是逻辑的复杂性，都会存在各种问题，所以架构设计时如果简单的方案和复杂的方案都可以满足需求，最好选择简单的方案
2、合适
合适优于业界领先，根据自身实际情况，采用适合自己的业务，应用，技术架构，不能生搬硬套。这也是哲学上所说的，客观决定主观。
3、演化
演化优于一步到位
- 首先，设计出来的架构要满足当时的业务需要。
- 其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善。
- 第三，当业务发生变化时，架构要扩展、重构，甚至重写；代码也许会重写，但有价值的经验、教训、逻辑、设计等（类似生物体内的基因）却可以在新架构中延续。
四、架构的演进
业务架构决定应用架构，应用架构需要适配业务架构，并随着业务架构不断进化，同时应用架构依托技术架构最终落地。
架构演进路程：单体应用->分布式应用服务化-> 微服务->service mesh
1、单体应用
- 非功能性需求的做法：
1）、性能需求：使用缓存改善性能
2）、并发需求：使用集群改善并发
3）、读写分离：数据库地读写分离
4）、使用反向代理和cdn加速
5）、使用分布式文件和分布式数据库
- 缺点
1）、复杂度高
2）、耦合性高
3）、可靠性差
4）、扩展性差
2、分布式应用
该架构相对于单体架构来说，这种架构提供了负载均衡的能力，大大提高了系统负载能力，解决了网站高并发的需求。另外还有以下特点：
1）降低了耦合度：把模块拆分，使用接口通信,降低模块之间的耦合度。
2）责任清晰：把项目拆分成若干个子项目，不同的团队负责不同的子项目。
3）扩展方便：增加功能时只需要再增加一个子项目，调用其他系统的接口就可以。
4）部署方便：可以灵活的进行分布式部署。
5）提高代码的复用性：比如Service层，如果不采用分布式rest服务方式架构就会在手机Wap商城，微信商城，PC，Android，IOS每个端都要写一个Service层逻辑，开发量大，难以维护一起升级，这时候就可以采用分布式rest服务方式，公用一个service层。
缺点：系统之间的交互要使用远程通信，接口开发增大工作量，但是利大于弊。
3、微服务应用
微服务的特点：
1）、易于开发和维护： 一个微服务只会关注一个特定的业务功能，所以它业务清晰、代码量较少。 开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的，所以整个应用也会被维持在一个可控状态。
2）、单个微服务启动较快： 单个微服务代码量较少， 所以启动会比较快
3）、局部修改容易部署： 单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。 一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。
4）功能纯粹、耦合性低：服务拆分，每个服务功能单一，耦合性低
缺点：运维要求较高、分布式固有的复杂性、接口调整成本高
4、service mesh
微服务的下一个阶段，即service mesh
Service Mesh 的核心其实就2个模块：SideCar 与 Control Plane
用来解决微服务架构中 服务间可靠调用、服务治理 等问题
大家有兴趣可以专门研究一下，在此不做过多讲述
五、衡量架构的合理性
架构为业务服务，没有最优的架构，只有最合适的架构， 架构始终以高效，稳定，安全为目标来衡量其合理性。
1、稳定性
1）要尽可能的提高软件的可用性：黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进
2、高效性
1)、 文档化：不管是整体还是部分的整个生命周期内都必须做好文档化，变动的来源包括但不限于BUG，需求。
2）、 可扩展：软件的设计秉承着低耦合的理念去做，注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代，并且支持在适时对架构做出重构。
3）、高复用：为了避免重复劳动，为了降低成本，我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。
3、安全性
保证数据的安全
- xss攻击
- sql注入
- csr攻击
- web防火墙漏洞
- 安全漏洞
- ssl
六、常用手段
- 应用服务器和数据服务器分离
- 使用缓存改善性能
- 使用集群提高并发和可用性
- 数据库地读写分离
- 使用反向代理和cdn加速
- 使用分布式文件和分布式数据库
- 异步降低系统的耦合性，提供系统的可用性、加快响应速度
- 冗余：冷备和热备，保证系统的可用性
