微服务的出现，仿佛秋天里的第一杯奶茶，给了互联网企业初恋的感觉，仿佛所有的问题都迎刃而解了。整个企业都在推进微服务的改革。
“某个技术难题攻克不了，大概是系统架构问题吧？老板，我们转型微服务吧”
“老板，我们这个新项目要开始了，现在都流行微服务架构，我们直接采用微服务架构设计吧”
“老板，现在云计算这么火，大家都在转型做微服务，我们也技术升级做微服务吧“
架构师们仿佛抓住救命稻草一样，不管三七二十一，轰轰烈烈的就开干了，遇到问题再说。遇到问题再说，那就晚了，对于架构师来说，顶多就是再换个老板，但对于企业来说，很有可能就是没了。微服务真挺好的，但是在你决定做之前，请做充足的调研，确认自己是否真的适合？
从微服务的定义来看，是把应用拆分成一个个的原子服务，服务与服务之间通过调用进行通信，每个团队维护一个服务，单独开发，单独上线，把之前业务之间的测试互相依赖、上线互相依赖的关系进行了改善。从研发需求开发上线及整体的流程来看，服务拆分成了微服务之后，每个微服务对应于一个代码仓库，按服务和仓库维度进行开发与上线，从一开始维护成本就很高。
当一个新人加入团队后，以前的单体式应用很方便于新人学习，只要在代码仓库将服务下载下来，本地启程序跑起来就好，模块与模块之间的调用不用管，在本地的代码编辑器很快就能了解到代码的业务逻辑。而当服务拆分成微服务之后，对于新人来说，学习成本是非常高的，需要有团队成员讲解这个服务的架构、微服务架构，再一个个的下载下来，解决服务与服务之间的调用问题，才能将服务运行起来，看代码时也是跨多个仓库查看，很麻烦。除此之外，根据统计数据，单体项目的每行代码平均成本是比较低的，随着项目发展和业务复杂度变高，代码开发和维护成本才会变高，而微服务的开发和维护成本一开始就比较高，随着业务和项目变得复杂，代码的开发和维护成本才逐渐降低。因此在技术改革时，需要根据当前项目的重要程度、可用资源等，来权衡找到最合适的架构方式。
在微服务架构中最理想的模式是每个服务都可以单独运行起来，有自己的业务逻辑、数据库、中间件、机器资源，当业务逻辑改变时，对应功能的开发和部署成本很低。在一个电商系统中，我们拆分成了用户管理、订单管理、库存管理、支付管理等微服务模块，当业务扩大后，我们需要再增加一个优惠券管理模块，增加的时候就比较方便，直接开发此模块的功能，在微服务网关中增加路由即可。
但随之带来的问题是如何管理微服务拆分带来的多个微服务项目，你可能需要最底层的硬件资源都是容器，便于弹性伸缩，再到开发、测试、发布、运维时需要全自动化的系统，开发上线时使用持续集成交付系统按服务按需求的快速发布上线，运维时通过全面的监控系统把握全局，出问题时快速找到解决方案。这些基础能力的建设与维护成本也是很高的。因此在技术改革时，需要考虑自己的业务是否需要快速迭代？自己的底层能力建设如何？不要本末倒置。
消息使用微服务技术架构必用分布式部署架构，分布式架构将单机部署的业务拆分成多个机器部署，可根据业务情况无限的弹性伸缩，实现高性能、高可用、高并发。
但是使用分布式也存在很多问题，比如数据一致性问题。提供业务的服务不可能让不同的用户访问到的数据不是同一版本，这样整体就都乱了，因此使用了分布式模式之后，跨服务的操作需要分布式事务保障操作的原子性、当多人对同一个服务操作时需要分布式锁保证该操作的原子性。这些都是使用分布式架构带来的额外成本，我们享受了它所带来的福利，也必定要为其付出代价。因此在技术改革时，需要考虑自己的每个业务都需要高性能吗？对于分布式所带来的成本能承担吗？不要因小失大。
服务没有拆分微服务之前，模块与模块的通信是内部调用实现的，没有什么网络延迟。但是当服务拆分成了微服务之后，模块就变成了微服务，微服务与微服务之间的网络通信就是外部调用实现，服务通信之间因为网络传输会存在延迟，而且如果网络通信出了问题，那么服务的整体服务质量就会变低。因此在技术改革时，非技术成本之类问题也需要考虑。
微服务是真的好，诸如阿里、京东、美团、滴滴等互联网巨头，都将自己的业务体系升级为微服务架构，全公司上线都是微服务体系，但是在整体改革中也付出了很大的成本，加上整体业务规模巨大、研发资源充足，才享受了微服务所带来的好处。我们可以学习借鉴大厂们的经验，但在实际开始去做之前，一定要结合自己本身业务情况、资源情况，再来衡量自己是否真的适合～
