微服务有它的好处，但微服务也不是银弹能解决所有问题，如果选择不对，可能适得其反。企业要有明确的业务目标和需求来推动微服务转型，而不是单纯的技术驱动。其次及时有了明确需求，也需要你前期进行相应的组织，团队和技术储备和积累，建立好相应的管控机制，否则导致的是一片混乱。今天分享一下微服务转型中常见的一些问题和时间思考。
本文节选自头条号：人月聊IT
01
单体应用不拆分是否就无法扩展？
单体应用存在数据库和应用两层，应用层往往容易集群扩展，而数据库是最难集群扩展的。如果数据库性能出现问题，优先要考虑的是代码和数据库层面的SQL优化（对于企业大部分应用来说性能问题不是服务器资源或能力不够，而是代码写的太烂。），其次是进行相应的读写分离或数据库拆分等。
02
传统单体微服务拆分颗粒度？
传统单体应用微服务拆分颗粒度为6到8个合适，这是一个毕竟粗的说法。但是传统应用本身存在流程驱动型和数据驱动型，类似OA或工单系统即流程驱动，这类应用拆分再多影响都不大，而对于数据驱动型如资产系统，那么务必注意底层共享数据层不要随便拆分，否则引入后续大量分布式事务问题。
微服务拆分和数据库拆分在我们实施总结两个概念要分开，数据库拆分后对应的上层应用模块你还可以进一步拆分为为多个独立组件，但是暂时不要去考虑独立部署。
03
微服务如何拆分？
微服务拆分是业务驱动而非技术驱动，需要深入地理解业务场景和业务流程，业务分析清楚后才能够明白哪些业务功能和业务数据应该聚合在一起，这样相互之间耦合性最小。不论是基于传统企业架构还是领域建模设计，核心都是基于业务驱动建模和拆分微服务。
其次微服务拆分要理解为两个层面的内容。其一是微服务模块和数据库的拆分，其二是拆分后接口的定义和识别。
04
是不是用了微服务框架就是微服务？
现在很多人对微服务的理解就是只要用了类似SpringCLoud等微服务框架就是微服务架构。这是很大的一个误解。微服务架构的核心在于微服务的拆分，粗粒度API接口设计，各个微服务之间的松耦合。如果这个要求没有达到不是微服务架构。
05
实施微服务需要哪些能力储备？
在技术上重点是对主流微服务开发框架的熟悉，其次是需要构建一个技术能力平台，实现共性技术能力下沉和共享，类似消息，缓存，4A，流程引擎，任务调度等。这些技术能力首先需要从微服务中剥离出来。只有这样微服务模块才能够将重心转移到对业务功能实现上。
在研发和过程管理上，重点是需要考虑开发团队的划分，敏捷方法论的推进，其次就是对持续集成或DevOps的过程实践。如果这些过程管理和自动化支撑工具跟不上，那么实施微服务往往带来巨大的后续实施运维工作量。
举个简单的例子，原来系统部署就一个大的WAR包，而现在变成了20个微服务模块，这个如果还依靠人工来完成显然是不现实的。
再次，微服务拆分实际和开发团队是匹配的，开发团队先拆分然后是微服务化的拆分，只有这样才能够彻底解耦。一个开发团队就2个人，一个后端开发人员管理拆分后的8个微服务模块，可以想象下这个开发人员完全无法做到按微服务边界和约束来是实现。本来该API接口调用的，反正都是自己做，又变成了直接访问数据库调用等。
06
为何微服务化后反而紧耦合？
这个实际是很多企业都遇到的问题，简单来说要给微服务架构的实施，如果微服务拆分后微服务间仍然没有达到解耦的目标，那么还不如不进行微服务化改造。
对于紧耦合的原因本身又体现在两点。
其一是微服务划分不合理，本来不应该拆分为2个微服务的你偏要去拆分，拆分后发现两个微服务间大量接口交互调用，自己给自己找麻烦。
其二是前期的微服务治理管控工作不到位，特别是对于微服务暴露的API接口的使用约束和标准规范等。在一个大的微服务框架下，所有的微服务共享一个服务注册中心，该微服务模块暴露的API接口完全可以被其它微服务模块访问和消费使用，也就是说微服务间的API接口访问和使用完全不受控，那么后续多个微服务间自然导致紧耦合的问题。
07
APM或服务链监控是否能解决服务治理问题？
再次强调下，APM或服务链监控可以帮助你改善和优化性能问题，服务调用不合理问题。但是这个已经是事后补偿操作，任何事情应该是需求和设计驱动，在一开始就避免问题，而不是出现了问题再变更和优化。
很多人观点是反正后续可以通过链路监控查看到服务链路调用关系和性能损耗等，那么在设计和开发阶段，我API接口随意调用也无所谓，这个是很错误的一个认识。包括很多人在实践微服务的时候又同时配合Scrum敏捷研发，导致微服务整个建设中完全没有架构设计工作，这本身又是一个给后期管控运维带来巨大的地雷的地方。
APM和链路监控不能没有，但是这个绝对不是你前期偷懒的理由。
高可用，高扩展和可运维
首先要认识到微服务架构下的高可用性设计往往比传统单体架构的高可用更加困难和复杂。前面谈到了拆分微服务的理由在于性能和可扩展性，以及业务能力上的解耦。
但是要注意到三者之间往往相互制约，当微服务化后性能和扩展能力确实提升，但是对于高可用性保障难度增加，对于可运维的难度增加。
很多企业在实施微服务的时候，前期在拆分的时候搞得很爽，但是后期发现拆分后的微服务太多，集成复杂度指数级上升，同时应用出现问题后连快速定位问题都难。这个也是典型的没有考虑清楚三者的均衡性问题。
●企业中台规划和IT架构微服务转型杂谈
●微服务架构设计实践总结和思考
●微服务设计-服务组合和可视化编排思考
菜根老谭，微信公众号：CGLT_TAN，人人都是产品经理专栏作家。经历程序员、技术Leader、研发Leader等多种岗位。关注医疗，早教领域，擅长企业IT架构及互联网产品架构。
点个在看你最好看