除非你已经是坐拥几十万粉丝的某领域大V了。很简单的例子，比如同样是关于热播剧清平乐的历史问答题。一个是影视领域的二十几万粉的大V来回答，一个是我这种几千粉的历史小黄v来回答。请问，谁的收益会更高？所以，综合来讲，问答这次取消领域的调整，对精准粉丝数比较少的创作者来说，其实是一个更大的挑战。但是，对于那些已经知道自己选错了领域的作者，或许，也是一次不错的机会。
系统软件架构中，现在很流行微服务，那么使用微服务就一定好么？微服务有哪些缺点呢？
下面简单回答下这个问题。在回答这个问题前还是先回顾下微服务架构。微服务架构概述微服务架构本质是单个业务系统彻底的组件化（前端，逻辑层，数据库）解耦，同时相互之间通过轻量的服务接口和协议进行协同。这和很早就谈到的组件化架构思想是一致的，实现微服务架构后，你会看到没有传统业务系统的概念了，有的只是微服务模块或小应用。
微服务架构最近又炒的相当活，很多人会说SOA过时了，ESB过时了，甚至还有人用微服务架构去彻底的否定SOA和ESB，这些都是相当危险的信号。在我12，13年写企业私有云PaaS平台的一系列文章的时候，已经提出了业务能力组件化，组件服务化的微服务架构思想，但是实际应用实施效果并不太理想。我们可以先看下从单体应用到微服务架构的变化图。
把这个核心搞清楚后，再来看下网上找到的对微服务架构的一些定义和阐述：微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。
如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。
如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。
