程序员如何蜕变成架构师( 二 ) _架构师

总结：简单优于复杂，无论是结构的复杂性，还是逻辑的复杂性，都会存在各种问题，所以架构设计时如果简单的方案和复杂的方案都可以满足需求，最好选择简单的方案
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）要尽可能的提高软件的可用性：黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进