互联网系统的诉求来自于多个方面，这里主要想突出三个方面的诉求：
- 来自客户：如果您的app粘沾度越高，诉求就越多，比如手淘的例子，体验要好、服务不间断等等
- 来自老板：老板希望能够快速迭代新功能或者新的想法以便跟上业务发展的节奏
- 来自自身：就是我们这些搭建系统的人，往往“希望”能满足以上多方面的诉求，而且也想少加班，不然累成狗，也费力不讨好
互联网系统大致可以分成三类东西：
- 第一类是业务系统，比如官网、CRM系统等等
- 第二类是大数据产品系统
- 第三类是分布式系统、大数据引擎与调度层、分布式存储、分布式消息中间件等等。
我一直在想能不能把这些玩意统一在一个类似数据中心操作系统之上，统一监控，统一治理，不过我发现也有不少人开始这样作了。
当前的微服务架构思路已经在风口了，这也许是业界述求的结果和期望，其实我和我的团队一直在思考和反思如何才能规划好和作好互联网系统，让它更加适应发展的需要，在有限的人员和成本控制下，如何满足各方面的述求，一直是努力的方向，所以微服务我们也开始尝试了，最大的难点却不在技术上，而是业务拆分上。
没有业务拆分就没有微服务架构，业务拆分的难度在不同组织中是不同的，这个与业务场景有关，况且业务架构的设计和前任、时代都有关系，很多创业公司，都是先让业务系统先能跑，然后慢慢优化的，结果基本都是10年前那种老旧架构，到了瓶颈改造的时候，留下一大堆的坑要踩。这就叫做：
oooO ↘┏━┓↙ Oooo
(踩)→┃你┃←(死 )
\ ( →┃√┃← ) /
\_)↗┗━┛↖(_/
所以我在实施微服务之前并没有考虑先把技术能力平台（分布式或者云的操作系统）设计出来，而是花精力整体到部分地去理解目前的业务系统现状、与各种相关人员聊，把思想统一了；
首先遇到的问题是，业务服务拆分的粒度！拆分的太细，因为根据责任单一原则，会变得服务非常细，此时我是感觉不妙的，这是因为这会给后续的调试和测试带来相当大的麻烦，比单一体系的调试和测试要困难的多，这涉及跨进行的调用、log不完整需要聚合、异常信息不完整等等的问题，我的做法是先做加法，后做减法，在全部细分出来的时候，回头来将这些服务根据重要程度、调用频率、容灾等等考虑上把细的分块合并在一起，让它们在同一个领域中就可以了，但是也要谨慎，就是不可以粒度变太大，那么就失去了灵活性、稳定性（比如一个整体服务挂掉，系统功能受到60%左右影响，就没有意义了）等等。
为了服务关系和开发上的清晰说明，减少沟通成本以及后期集成、维护成本，必须形成服务关系与API文档，API文档是个很精细的工作，过去不少人会这样干，比如一个获取最受欢迎的商品时，有人设计一个叫做queryBestPopGoods的API，仔细思考一下，这个貌似没有问题的API，其实存在将服务腐化的危机，因为大部分人会和需求一对一的设计API，这个问题就出在这里，试想一下，如果有10000个需求，我们就对应10000个业务API？会使得服务越来越膨胀，内部的调用越来越复杂，腐化在所难免，怎么办？有句话叫做把业务装到技术里，就如apple的一个物理按钮可以干N多事情一样，需要做一个技术设计，比如我只提供一个叫做queryGoods的API，内部按一种查询引擎的方式设计，然后调用方只是提交“我想要哪些领域、哪些字段的数据”之类的请求，由这一个API可以覆盖所有商品查询的能力，不过有人说那会不会慢？API数量和调用性能没有直接关系的，难道google的一个文本框就决定了它性能不好？我不知道为啥有这样的观念存在，本质上并不存在API数量和性能的关联性的，因为一个查询在后端的是分解的，是分布式的。
再者需要设计一种插件结构，将服务继续“瘦身”，这受到操作系统和eclipse的启发，设计一个微内核，让功能按插件的形式插入进来，我们采用SPI的方式将业务插件插入到服务微内核中，使得它更加灵活。另外在服务启动时，他会自动将自己的API拓扑元数据注册到集群中，这样可以一目了然整个API的分布情况，再加上traceId所跟踪的调用链，很容易看到水平和垂直的调用关系，之后我还想将集群中各个部件（比如redis，mysql）等的执行架构可视化，可以通过JSON说明和维护架构的模式，比如我在一个图形化的界面上能看到架构，然后调整它，转成JSON文档提交给集群管理器，它自动拉取镜像和代码、自动调整执行架构。
最后我要把规则抽取出去，变成一种新的业务服务器形态，上层搞出来一种领域DSL，交给业务方和我们一起共建系统，这个想法最终实现是基于规则引擎的元数据管理平台，进一步地让业务开发无服务器化，越前端越业务化。
在业务水平和垂直拆分设计之后，有了一定的基础，我们开始考虑设计技术能力平台的事情了，想出了几点要求：分布式能力透明化、运维监控一体化、服务治理统一化等等，想统一基础设施，而不是不同系统有自己不同的分布式底层架构，让业务系统变成彻底的前端系统。这个是个长远的打算，目前进度压力还是有的，我综合各种因素，决定采用CAAS（容器即服务）的方案，
- 第一Docker可以最小化测试环境与生产环境的差异，做到平滑部署；
- 第二不必以后重复性的准备物理机到部署的繁琐工作；
- 第三Docker的管理上需要能够抽象一套应用层面的管理API，比如把一群同构Docker抽象成Service接口，而调用方不必关心Docker的存在；
自己管理虚拟网络，部署时一键搞定（集成CI）。第三，应该将架构拓扑以元数据的形式保存下来，集群管理器可以根据外界提供的JSON配置式的部署服务、管理服务扩容或者索容、关闭服务、修改执行架构等等。最终我选取了Kubernetes作为我们的CAAS平台。具体的K8s实施情况，后续的文章将会讲到。
最后我是想把大数据系统也搬到一起的，不过需要做到资源隔离，也就是在一个大物理集群中，只允许大数据系统和业务系统各自使用一组机器，但是能力平台对他们来说是一个透明的、统一的平台，由能力平台提供的多租户隔离管理能力运用在此方面是不错的想法，让不同系统公用基础设施，但是在资源调度上保持独立性，防止类似大数据这样的CPU计算密集型应用与业务系统争夺资源的情况发生，并发不稳定的情况，系统之间可以考虑使用kafka之类的分布式消息中间件进行关联。
以上，是总体的心得，以后的文档会展开细节讲解，也是在实践中得到的一些心得体会。
本文作者 高磊（世忠）
