现有的应用不是微服架构有必要做改造吗？

微服务，在互联网企业甚至传统行业移动端业务得到大规模采用，已然成为主流的应用架构。

微服务旨在帮助组织实现两个基本目标 - 敏捷性和规模 - 因此首先要评估组织的需求。

敏捷性：笨重单一的应用程序或ESB基础架构可能需要长达数个月的部署时间，从而导致冗长的发布周期，阻碍组织跟上市场需求的能力。在构建、部署、扩展和管理各个服务时，微服务可以使您转向更灵活的持续交付环境。

规模：对于希望更有效地利用现有硬件资源的组织，微服务可通过容器化提高计算密度。另一个可扩展性要求可能是快速弹性以适应峰值负载并在非高峰时刻减少资源 - 例如，亚马逊能够处理各种促销活动的购买量或Netflix在新节目发布时处理流量的能力。随着组织的扩展，一致的性能是另一个特别关键的需求。如果您需要更新应用程序的某些部分，微服务架构可实现独立部署和扩展，而不会影响应用程序的其余部分。

如果有敏捷性或者业务规模扩展的需求，建议对现有应用进行微服务化改造。同时随着微服务架构的落地，DevOps将会成为加速业务价值流动的重要一环。

其实使用微服务架构还是使用原本的单体架构，都取决于需求，那么问题就是我们目前是什么样的需求。需要微服务架构的，一般面临以下几个需求：
1.更新迭代太快，而部署麻烦，每次都要花费很长时间，经常影响业务。
2.公司的应用有几十个，重复的模块很多，也无法统一管理，未来还有扩展的需求。那就不如趁早转微服务架构，另外需要一套服务治理平台。
3.应用中某模块使用频繁，并发率很高，或有高峰期，经常需要资源的扩容缩容，单体应用做集群部署勉强能满足，但运维成本翻倍上升，且可用性下降。

1.微服务架构是随着业务发展要求出现的，不要为追求新技术而上“微服务”。
2.一般解决现有业务的高并发量问题和快速迭代开发需求，或业务发展方向的要求，才考虑上微服务架构。
3.微服务架构是分布式架构的一种，先要对应用架构进行架构改造。实现分布式的应用架构，然后逐步拆分服务，封装服务，最终实现微服务架构。

这个如何回答哟，有得必有失。

微不微服务的无所谓，核心是业务架构设计，功能逻辑解耦。
任何框架，表象是技术，实质是一种新的设计思想。
别为了技术而技术。

微服务改造的代价很大，动手之前一定要评估 - 微服务到底能够带为现在的应用来什么好处。慎之又慎呀。如果开发新应用倒是可以尝试微服务。

确实为了微服务而追求微服，之后增加成本