服务的大小并不重要
微服务这个术语的一个问题是会将你的关注点错误地聚焦在微上。它暗示服务应该非常小。实际上，大小不是一个重要的考虑因素。
更好的目标是将精心设计的服务定义为能够由小团队开发的服务，并且交付时间最短，与其他团队协作最少。理论上，团队可能只负责单一服务，因此服务绝不是微小的。相反，如果服务需要大型团队或需要很长时间进行测试，那么拆分团队或服务可能是有意义的。另外，如果你因为其他服务的变更而不断需要同步更新自己负责的服务，或者你所负责的服务正在触发其他服务的同步更新，那么这表明服务没有实现松耦合。你构建的甚至可能是一个分布式的单体。
微服务架构把应用程序通过一些小的、松耦合的服务组织在一起。结果，这样的架构提升了开发阶段的效率，特别是可维护性、可测试性和可部署性，这也就让组织的软件开发速度更快。微服务架构也同时提升了应用程序的可扩展性，尽管这不是微服务的主要目标。
进入服务化架构的误区
业务早期进行服务化阶段要慎重
笔者旗帜鲜明的反对早期就进行过度服务化的考虑。比如以一个代驾业务为例。我的想法，服务端程序早期一个war就够了；移动端涉及到安卓、ios甚至小程序需要考虑多端问题。至于用户服务、用户选择代驾、代际服务入驻等都可以慢慢来。说不定，一年，这条业务线又关了呢。
淘宝和支付宝往往是几百人维护一个前台和后台系统，才进行服务化拆分。当然当时还没进入移动时代，就需求上线特性的速度来讲，也不是太慢。按周进行发布。在一个单体架构中，进行较好的模块化，按照团队分而治之。研发态的团队组织关系和发布态的可以辩证看待。不是说那段经历是完美，是说明可以容忍，甚至不是最关键的阻碍，在支持业务上。
建议在单体架构阶段采取较好的架构决策，而不是匆忙进行服务拆分
同样，在Medium，他们在早期的单体应用程序中做出了一些很好的架构决策。
他们的单体应用程序由组件高度模块化，即使它已经发展成为一个非常复杂的应用程序，包括Web服务器，后端服务和离线事件处理器。这使得将一大块业务逻辑剥离到单独的服务相对容易，只要新服务提供与原始实现相同（高级）的接口即可。
整体应用程序在较低级别封装了数据存储详细信息。每种数据类型（例如，数据库表）具有两层实现：数据层和服务层。
- 数据层处理对一种特定类型数据的CRUD操作。
- 服务层处理一种特定类型数据的高级逻辑，并为系统的其余部分提供公共API。服务不共享它们之间的数据存储。
- 这有助于我们采用微服务架构，因为一种类型数据的实现细节完全隐藏在代码库的其余部分。创建新服务来处理某些类型的数据相对容易且安全。
单体应用程序还可以帮助我们对微服务进行建模，并使我们能够灵活地专注于系统中最重要的部分，而不是从头开始为所有微服务建模。
一些bad case 供参考
一：组织和服务划分配套。
曾经有一个国外的case，没有做对应的改变，导致微服务没有owner。他们大约有12个开发人员分布在两个功能团队和一个支持团队。工作波动性很大，没有专职负责团队。所有团队同时接触同一批代码很正常，不能将某个微服务指定给一个团队。
考虑架构时候一定要记得Conway's Law，其意思是软件架构会模仿组织和团队架构增长。微服务架构对于不同团队负责不同业务逻辑是比较有效的，然而，共享代码功能的工作模式最好采用单体式架构。
二：谨慎引入新的技术栈
某一个创业团队，由于技术负责人的喜好，引入了go语言做微服务。后来又由于招聘困难，同时维护了java语言的一套服务，分别取名V1.0，V2.0。目前升级V3.0 暂时还没有把V1.0下线。后续的维护成本是一个问题。
三：过犹不及的服务数量
Uber支付体验平台的工程经理Gergely Orosz称其所在的团队正将许多微服务转移到宏服务（macroservice，即大小适中的服务）。
他们声称在构建新平台时，在新服务方面做的规划要周到得多。这些服务不仅仅只做一件事：服务于一个业务职能部门。它们由一个团队（5至10位工程师）构建和维护。与那些早期的微服务相比，它们更具弹性，并且在开发和维护方面获得多得多的投入。
我的意思是当大家在学Uber的时候，最好一开始就想好服务粒度。
总结：
可能进入服务化阶段的几个征兆：
1、开发人员庞大，比如大于100人。众多人维护一个系统变得不可行，代码冲突和代码分支众多可能导致成本。
2、代码逻辑复杂，缺少层次。改动代码成本高，系统脆弱。如早期蘑菇街采用php ，后转向java，同时实现了服务化。
3、业务多元化发展，共享业务服务逐步凸显
我们说服务化，便于服务/能力共享，总要回答共享什么嘛。多业务发展让服务共享具备可能性。否则也就是沉淀一些会员服务。
4、扩展性瓶颈
比如数据库链接，系统共用的底层资源随着机器增加而大幅度增加。比如对于单体应用中的支付模块，订单模块需要不同的tps/qps要求。
当我们应用微服务/服务化，我们大致从这些维度进行评估。只有想清楚了，才能评估实施后的收益和成本支出。
微服务架构谈系列预告
之二：思辨SOA和微服务
之三：服务化对于研发利好是过程，对于业务反应效率才是结果
之四：服务化架构承受之重：增加了哪些复杂度
之五：分布式事务
之六：服务治理和监控
