微服务拆分和设计，以及应用中的风险

现在软件开发很大的问题就是紧跟大企业的脚步，只要大企业采用了什么技术，很快就会普及下去，开发人员一般不会细细分析自己是不是真的需要这种技术。

这个行为很大程度上是开发人员的自我的技术投资，毕竟开发人员如果有机会采用这些流行技术，也会让自己在有些场合比较有优势。

但是这种情况往往浪费人力资源，比如像微服务这种技术，而这种技术并不是非常复杂，而是在于上层设计。

由于独立性，无状态，可以随意布置和分布式扩展，所以需要做很多细粒度的拆分，导致开发实施上都会很麻烦，对每个接口的跟踪监控也更加复杂。

我们看从中间件-SOA-微服务的演进过程中，其实中间件技术已经可以抵御绝大多数的应用场景，利用中间件的思想去搭建中台也应该是开发人员默认的思想，需要更多场景可以考虑SOA，微服务说说就好。

我们看到仍旧好多人员采用微服务架构，但是面对所谓的适度的拆分，往往是让人头疼。

适度，适什么度，真么算是合适，这些都是让人无法躲避的东西。

首先要确定什么东西放到微服务环境，什么东西还是只是做普通服务调用，不要把一切都扔上微服务，拆分很重要，并不是所有业务都需要用微服务去分割，集中统一我相信仍然是大部分后台系统唯一正确的集成方式。

首先保持微服务绝大数是技术服务的统一提供接口；其次是非常通用的，甚至是完全可以移植的业务接口，集中大体量的业务访问量；最后是工具组件部分。

如果是纯业务，或者后台管理平台，还是完全集成统一更有利于开发，变更，调整。

而微服务保证接口的单一原则，这个也是面向对象开发最终要的原则之一，就是服务所干的事情是唯一的，不会中间去完成另外一件事。

微服务要在整个环境的语义下，探索接口的定义，如何承接上下文，如何规避业务风险，如何定义统一的接口含义，如何监控等等。

就是说这是说：说话很重要，表达很重要，在统一语义下的表达，可以让整个环境理解的统一的格式，统一的协议接口。这个需要开发团队合作共同制定这些规则，形成一致性的调用和维护体质。

保持简单的模式，尽量保持简单，形式和语义的简单方便学习和理解。

微服务是单一功能和无状态的所以不应该和其他业务发生强耦合，如果是微服务中有依赖就要看看是不是要整合。如果发生如果不拆分两者都会在应用场景下缺乏表达，这个就要检查是否是设计的问题了。

每个微服务要有明确的表达，利用组件获取别的服务，而不是本地服务来相互调用，并且不应该害怕失败，有完整的错误处理环节和记录。

所以拆分微服务是一个业务和技术重新整理的过程，如何设计才是整个工作的大前提，最好是利用成熟项目，一点点的分析拆分，规划和合并。

建议微服务是一个小型的生态环境，提供有效，高效的中间层，通过领域模型定义和提炼服务协议和表达的语言。

微服务也是服务，应该让人随时监控，数据，内存，服务运行情况等都需要让运维人员知道，同时有快速替换的方法。回退方法。

虽然上面提供了一些经验，但是还是不推荐开发去选择微服务，微服务给运维开发都带来可一定的开发困难，同时对业务建模提出了非常高的要求，而devops对我们大多数开发团队来讲要求又太高，往往业务开发都会因为在微服务中调试问题而耽搁。

中心化的开发模式，我相信仍然是有生命力的，仍然是一个新项目开始最佳的模式，只有你的量真正发生改变，你才需要逐步转型。

但是有一点很是要鼓励，及中台系统，这是一个很好的提升团队能力的思路，提升业务的产品化，抽象业务组件，简化开发都有很好的思路，所以中台化比只是选择微服务话要更合理。中台化需要整个开发团队的技术信仰和执着。