上一篇 中，我们提到了可靠性、高性能、伸缩性和扩展性。其中扩展性没有进行说明，本篇就通过单体应用到微服务架构的转变，来看看可扩展性。
单体系统有什么缺点呢？（微）服务化系统又有什么优点呢？我们不妨换种角度来看：
将单体系统看成一个类
那么可想而知，随着系统功能的增加，这个类对外要暴露的方法也在不断增加，代码行数也在不断增加。一个一万行的类，你觉得缺点是什么呢？
当然了，如果系统功能不多，也比较简单，那自然是没问题的。
那么，服务化系统呢？
服务化系统就相当于引入了设计模式的思想，从整个软件架构去考虑。遵循高内聚低耦合等原则，将这个单体大类进行重构，最终拆分成了好多个不同功能的类
当然最大的问题是提高了复杂性以及需要对系统有深刻的理解。
那谁来承担这个重构的角色呢？当然是架构师啦。扯远了~
站在面向对象设计角度，我们可以把系统看为：类 + 类之间的交互。
针对服务化系统，每个类就是一个服务（也就是一个单体应用）。类的设计追求的是低耦合、高内聚。基于这个目标，我们的服务划分方法就可以归纳如下：
-
根据业务流程来合理地划分
-
每个服务内部，又可以选择执行进一步地拆分
而类之间的交互追求的是最简原则，交互越少，系统就越容易扩展维护。思想可以归纳如下：
-
分层思想。将各服务归类分层，上层服务调用下层，下层不依赖上层。这也是为什么系统普遍都是分层架构
-
中间件思想。引入中间层，就如同数据库设计的N:N映射一样，通过引入中间表，将其变成了两个 1:N关系。引入中间层，会极大减少错综复杂的交互。这同样是消息系统或者以前的系统总线等流行的重要原因。
所以说，知识都是相通的。就算不是架构师，你在编写软件的时候，同样会涉及到 类 + 类之间的交互 ，对业务功能理解的越透彻，当然会设计的越合理。实际上，（微）服务化架构最难的点就在于如何让业务很好的映射为整套服务系统。
从面向对象这个角度来对比单体架构和服务化架构，相信你在自己思考后会产生不同的理解
我们这里再回答一个问题：
为什么要进行服务划分？
系统的业务场景是流程性的，比如用户登录->查看商品信息->购买下单等。如果这些功能都在一个应用（服务）中，则站在软件设计的角度，就相当于 面向过程设计。
反之，如果划分成 用户服务、商品服务、订单服务等，再由这些服务对外提供功能，则站在软件设计的角度，就相当于 面向对象设计 。
这样，我们就将矛盾变成了：
面向过程设计和面向对象设计的对比
这里就简单说一点，即为什么大型系统或者说许多领域都是按照面向对象思维去设计的？
我们常听说的面向对象设计语言，其实是说这些语言提供了方便进行面向对象设计的特性。虽然C语言没有提供相关的特性，但也不妨碍我们利用C语言编写符合面向对象设计思维的程序。比如Linux内核中，许多底层实现都是基于面向对象设计思想的。
总结就是一句话：采用面向对象设计思维，比面向过程更加容易和更加可能设计出可复用、可扩展、可维护的程序。
同样类比程序设计，以前的服务化，因为没有现代的技术，比如K8S或者微服务框架等等，就好比只有面向过程这种语言。技术人员只好使用这些“面向过程设计语言”来建模。但同样不妨碍出现了许多优秀的系统。
只不过随着系统越来越庞大，以及现代技术的出现，如K8S，微服务框架和微服务思维等等，即出现了“面向对象设计语言”。技术人员就可以直接利用这些“语言”来进行建模。
服务化之后，针对不同的需求，只需要修改对应的服务内部实现即可，扩展性自然变高。
我们再来谈谈系统架构和系统集成的区别
这张图是 spring 官网的一张图，请问这是系统集成还是系统架构？？？
这是系统集成
如果让你给出系统的架构，结果仅仅给出了这张图，则只做到了系统集成。因为仅仅是将各种开源组件集成到了一起，我们上面的文字说过，系统架构必须 对业务有深刻的理解。这张图里根本看不出对业务的理解是什么？
那么什么是系统架构呢？
随便搜了下，看见满屏的花花绿绿的小图了吗？很明显存在了各种层次的划分。
首先你要知道整个系统划分成什么子系统，比如运营平台、商户平台等等，还要清楚地知道比如运营平台中涉及到什么功能，这些功能又如何划分成服务，服务又该如何实现，系统各种异常等怎么应对，比如熔断限流等怎么设计等等一系列，这些才组成了系统架构。
再扯远一下~~~ 实际上，软件开发最难的一步，是业务功能到可设计开发的系统的映射：
最后，再扯一下~~~ 为什么微服务会越来越流行，当然已经很流行了，以及K8S给我们带来了什么：
本篇就到这里，下一篇，我们再来谈谈微服务架构和中台架构。本文spring官网上的架构图中，有一个API Gateway，这货到底是要干什么？这也是下一篇要阐述的。
