【问题】你用过面向服务架构吗？能否讲讲你对架构的认知。

这个问题有点年头了，那时候面向服务架构（以下简称“SOA架构”）还非常火。现在国内谈微服务架构的比较多 SOA 架构的少，这几年谈微服务架构的也少了，可能是因为企业“降本增效”的缘故吧，大家又重新投入到单体架构的怀抱...

但不可否认的是 SOA 架构还是有它先进性的一面（从 1996 年 Gartner Group 首次提出了“服务导向架构”的概念到现在已经 27 年了），可以说前几年火了一把的微服务架构也是在其基础上延伸的。

我的理解 SOA 架构和微服务架构区别在于，SOA 架构适合大型复杂系统，它可以提高系统的灵活性、可扩展性和可重用性。微服务架构适合快速开发和部署的系统，它可以提高系统的敏捷性和可维护性。再用一句比较好理解的话就是，SOA 架构是“应用”独立服务做分布式，而微服务架构是“功能”独立服务做分布式，这会不会好理解多了。

PS: 天底下哪有这么多大型复杂的系统。特别是最近几年的行情，大家有 idea 都想尽快上线抢占市场，微服务架构无疑是最好的选择。做大做强后实力强劲的就继续延伸拓展，实力没那么强的先单体提供服务即可，只要先赚一笔怎样都可以......

扯远了，回到题目。

嗯...虽然 SOA 架构没用过，但微服务架构却经常用，但随着微服务增多，服务治理是一大难题（里面有太多的坑了，网上大神们都应该有说过），所以我认为一家公司如果是初创公司且公司规模能逐步正向发展的话，那业务架构应该是这样进行演化的：

1. 单体架构：这时整个系统就是一个应用，直接采用社区版的 MySQL 关系型数据库存数据，用 Redis 做缓存和简单的消息队列即可。

   之后购买一到两台云服务器进行托管，在上面用 Nginx 做反向代理直接部署一套水平的高可用就基本能满足要求。

   创业前期资金流比较重要，不需要加入太多技术栈把系统复杂化。你要想着除了系统外还有一大堆东西需要做，像推广、运营、策划等等这些才是要烧钱的地方。只需做好基础架构的性能调优，快速抢占市场才是王道（大部分初创公司都永远定格在这个阶段，不是技术问题就是管理问题）。

2. 服务架构：当 UV 、PV 等数据上来后 99 % 会觉得资源不够用了，性能变差了，网络波动了......又恰巧赚了些钱了，心就开始痒痒了。一遇到问题就会想到做水平扩展就好了 =_= ||

   并不是说这种做法是错的，站在业务层面来说，毕竟公司发展还有太多东西需要关注了，能花钱的花钱解决就好，时间就是成本。但站在技术的角度来说，这种做法紧急情况下可以，但缓解压力后我们还是要复盘找到根本原因。 其实这时是全面梳理和审查代码的最好时机，看看还有哪些问题一并解决。若能通过代码修复解决性能问题是最好的，实在不行就只能考虑将某些耗资源的服务拆分成多个实例，通过负载做成资源倾斜的面向服务架构。

   一般来说通过以上方式又可以“再战几年”，但还出现性能瓶颈的话就真的要深入排查一下了（毕竟业务量、访问量、流量数据等数据结合可以粗略推测出压力情况，配合 Dump 分析应该能够知道个大概了）。若不是逻辑处理问题的情况，大概率是存储结构的 IO 性能问题，如果真是这样可以考虑增加 NoSQL来处理非结构化数据，用一些功能强大的 MQ 来实现服务间异步通讯（如：RabbitMQ、Kafka 等等）。

   这个时候其实还不需要全面改变成微服务架构，因为程度还不算严重无需大动干戈。再补充一点，在我的理解里面只有遵循 IBM 提出了 SOA 参考模型的服务架构才能够算是 SOA 架构。不幸的是，目前我遇到过的公司的服务架构都不能称之为 SOA 架构，他们顶多是因为资源问题做水平集群拆分而已...

3. 微服务架构：当服务架构也不能满足资源要求时只能再进一步分析和拆解（有的小伙伴可能会说加资源就可以了，但是资源是要“钱”的，你再想想你老板的那个抠搜样，总不能够一直加吧...），个人觉得这时可以考虑两步走，第一步清理屎山代码，第二步微服务化。

   这时又有小伙伴会说“屎山代码、祖传代码哪有那么好清理？你以为清理不用成本吗？”其实代码审查（code review）这个事情并不是出问题时才做，开发人员在日常工作中就应该包含这一块定期执行的。目前新版的 Gitlab 就有代码审查功能，其他的像 SonarQube、Spotbugs 等工具都能够很好地做自动化代码扫描，不过这个还是要看各家公司自己的情况，不过实施起来问题不大。

   到这时候数据肯定有一定量级了。数据实时运算就不要再用 MySQL 苦苦支撑了，可以考虑采用流处理框架 Apache Flink 来做（用过感觉还挺好）。运维方面可以初步上一些虚拟化容器，譬如 Docker 和 K3s 等等配合编排、管理工具使用效果会非常不错。

4. 超大型微服务架构：这一层面的架构我是没有接触过。据我了解，这规模的微服务数量是已经超过上百个甚至上千个，将会针对核心服务采用数十上百实例的大规模水平扩展，拥有服务自治、自恢复能力，云原生架构体系等等。这没有接触过也不敢随便说...

再之后的应该就是响应式架构、Serverless 架构、边缘计算等等架构模式，只不过能力有限暂时还没有去到这些层级了。