软件架构需要考虑的基本原则

1、稳定性原则

架构尽可能的简单，清晰，不过度设计。

2、注意隔离处理

稳定业务和易变业务要分离处理，核心业务和非核心业务要分离处理，电商业务和辅助流程要分离，应用和数据要分离，服务和实现细节分离，前台和后台分离。

3、抽象化

1. 应用只依赖于服务抽象，不依赖服务实现细节。
2. 应用只依赖逻辑数据库，不关心具体的数据库位置和分片。
3. 应用虚拟化部署，不关心实体机配置，动态调配资源。

4、松耦合

跨域调用尽量异步化，非核心业务尽量异步化，必须同步调用时，要设置超时时间和重试机制。

5、容灾设计

1. 服务要自治，彼此能够独立修改、部署、发布和管理，避免引起连锁反应。
2. 通过集群容错，应用系统集群，避免单点。
3. 多机房容灾部署，多活机制，避免出现单机房崩溃情况。

6、什么是架构师

架构师首先是对技术和业务都全面了解的系统设计师，架构师可以不用写具体的业务实现逻辑，但是他必须对系统整体采用的技术及其业务流转过程非常熟悉，这样才能够根据实际业务需要给出最合适的架构设计。最好的架构不一定适合业务，适合自己的才是最好的。

其次，架构师应该密切关注技术前沿，能够采用一些新的技术对当前繁杂的业务进行变革，从这个角度上讲，架构师又承担着变革者的角色。举一个很简单的例子，一个常规的项目，如果没有架构师，经过半年时间也能设计完成。但中间可能会经历很多不必要的重复劳动工作，而且最终产品的稳定性可能欠佳。如果有一个称职的架构师参与，这个系统可能三个月就完成，期间的重复劳动可能会减少，同时最终产品的稳定性应该也有所保障。架构师更多的工作应该是预见未来，多做一些防患于未然的工作。

当前技术团队的人员众多，根据管理学上管理幅度的理论，一个管理者管理8-15个人比较合理，这样既可以有足够的精力思考公司战略，达成业务，同时又有精力去培养人才。

转自：https://blog.csdn.net/zyhlwzy/article/details/78085865