如何设计实现一个通用的微服务架构？高可靠、高可用思维模型

1KW房产+1KW腾讯股票+300W现金=35岁提前退休

看帖子内容，300万是这些年995拼了十多年攒下来的工资，算下来虽然不少，但对于大厂程序员的收入来说并不夸张。

程序员职业发展路径大体可归纳为：技术流和管理岗。不管是否走上管理岗，在技术方面逐步精进是必经之路，而架构师是这条路上承上启下的关键一环，是大部分程序员的目标。

术业有专攻，程序员也是如此，有的擅长编码，有的擅长底层原理，有的擅长逻辑实现…但凡在一方面做到精通，我相信你在团队里都会是核心成员。

而放眼更高层架构设计时，很多开发者就常常面临需要突破的困境。

就当下的技术环境而言，最热且被讨论最广的非微服务架构莫属，自阿里2008年最早尝试微服务至今，经过十余年的发展微服务渐渐成为主流。

当单体发展成为难以驯服的野兽，开发效率、代码维护、部署灵活度、稳定性、扩展性等持续走低、维护成本越来越高，大家开始纷纷拥抱微服务。

当然，没有任何一项技术是完美的，如果只是找个工具，硬往上套需求，往往不仅解决不了现存问题，还会引入更复杂的问题。

想要构建一个稳定、高效、易扩展的微服务应用，有几点需要思考：

进行服务拆分，边界在哪儿？

怎么取舍？什么样的粒度才符合“高内聚、低耦合”？

分布式事务是采用简单的重试+补偿机制，还是采用二阶段提交协议等强一致性方法来解决，如何权衡？

架构是为业务需求而生的，是多方权衡的结果。系统中的个体需要“根据某种规则”运作，架构的任务就是需要明确个体运作和协作的规则，解决因系统复杂带来的诸多问题。

对于任何一个想成为架构师的程序员来说，判断与取舍都是非常重要的思维。