我对软件架构高可用的思考

type

status

date

slug

summary

单块应用的高可用

我个人认为，软件架构的高可用不仅仅是需要保证能够对外提供服务，满足调用方以及客户的需求，更应该是能够持续提供稳定的服务，这就要求首先需要保证我们在服务开发过程中，需要从以下几方面考虑到软件的可用性：

可扩展性：扩展性意味着需要为服务之后可能会进行的改造进行考虑，在设计上需要遵循软件设计的开闭原则，这样才能尽最大努力来保证原有结构的稳定性，而不是每次重构都是大刀阔斧的修改，那样会给架构带来更多的不确定性；

资源隔离：对于当前服务中需要依赖外部服务的调用，应该进行资源隔离，屏蔽第三方系统的不稳定性，同时任何对于第三方服务的依赖需要考虑降级方案，确保当前服务的健壮性；

软件测试：软件开发完成后开发者首先需要保证个人开发模块的单元测试能够覆盖所有核心业务，团队开发准则应该需要设置单元覆盖率保证；移交给测试团队的版本需要确保进行过简单的冒烟测试；对于测试团队来说，需要考虑集成环境下各种复杂的边界情况；对于项目中引入的大的变化，应该尽可能使用A/B测试来收集用户反馈，这样也能够将新版本的不稳定性控制在一定范围内。

只有单块服务能够保证服务稳定性的前提下，微服务的分布式部署才更具意义，否则客户端调用时经常出现接口调用超时甚至异常情况，从本质上就无法保证高可用时，一切外部努力都是徒劳。

首先在微服务架构中，每个服务的边界较为分明，服务的职责也比较清晰，但是如果使用了微服务架构，那么就势必需要进行服务的分布式部署，多机房部署以及跨地域的部署，这样才能够保证即使出现服务所在机器宕机或者机房故障，仍然能够保证对外提供服务。

当然对于现在云环境日渐成熟的情况下，选择将服务部署到云上也是不错的选择。

在个人看来，一个优秀的技术团队，技术负责人首先需要能够把控项目的整体架构，对于项目中的重要模块，应该确保团队中有最少两位高工熟悉核心模块，这个是为了确保人员稳定性对项目结构带来的影响。

在我所在的机器人公司中，我们从生产到软件研发包含很多团队，每个团队符合机器人交付的不同需求。

例如生产团队需要负责将采购的各个部件进行组装，按照图纸装配出最终的机器人成品，这个组装出来的成品能否正常工作就要交付给测试团队来集成测试。

测试团队需要首先验证各项基本功能，但是在测试中，如果某个部件出现异常，比如部件异响，就需要对某部分组件进行独立测试。

在软件研发团队同样如此，如果新开发的功能某部分出现问题，同样需要复现问题进行针对性测试，在测试之前同样需要出具详细的版本说明以及测试说明，这样才能让测试团队能够按照要求进行测试。