本来是打算写一篇介绍我目前工作中有意思的设计的博客，写着写着发现设计的知识点还是有点多的，因此这里单独增加一栏，用来不断的更新相关的内容。
由于工作的变化，我从图像算法和框架，转向了服务端架构。做服务端架构，相较于算法和sdk框架，有着挺大的区别。而适应这一变化，确实需要花费挺长的时间，也学习到很多。
服务端的概念很多，很难在一本书上找到所有的答案，平时也只能自己多问多摸索。
这里总结了一下日常遇到的有意思的概念和技巧，希望耐心看完本文的你能够更快速的理解服务端的概念和开发过程。不至于在入职时每次讨论都一脸懵逼。
另外，我会在各部分的章节中，插入一些工作中遇到的真实案例。事实上，由于这些案例太过有意思，让我忍不住分享出来，所以才有了本文。（本文的目录也是根据这些案例归纳出来的。）
架构即设计
“架构”一词，在我换工作之后几乎每天都会听到，在我眼中是个高大上的存在。在具体接触到大家提到的架构设计的具体实践之后，我明白了一件事情，任何一个设计都可以认为是一种架构，而架构本身也有“好”、“坏”之分。因此，当发现很“挫”的设计的时候，我们可以说这是一个不合理的“架构”，或者是为了迎合当时的需求的特化的“架构”。
这里，我理解“架构”其实是“设计”的别名。
架构解决的问题
那么一个好的架构，需要解决什么问题呢？
前端架构，可能需要的是高性能、可拓展、易上手、兼容性、体积小等目标。后端架构可能是稳定性、高并发、一致性、快速迭代等目标。
问题不是单一的和明确的，针对不同的业务场景，我们需要随机应变。需要理解在每种设计下，带来的优势和弊端，就像刷算法题一样，我们会分析时间复杂度和空间复杂度。对于一个架构设计而言，我们也有许多的指标，比如：CPU、内存、带宽、磁盘、扇出、扩容、容灾等等。没有银弹，好的架构需要的解决的目标有十分清晰的认识。
在工作中，其实可以看到许多的架构的设计，比如最常见的RPC通信的参数的设计、正排服务的存储选型、服务发现的策略、一致性Hash的不均等。本系列的愿景是将这些有意思的问题和可能的方案，整理和分析。
本系列的内容
本系列打算按以下方面进行介绍：
- IDL，不同IDL的区别和优劣
- 服务状态指标，对于服务程序，我们需要从哪些维度去观察
- 服务拆分，高并发下，业务的水平和竖直拆分
- 一致性Hash，和服务拆分相关联的技术
- 降级，在突发情况下，比较常见的降级手段
- 缓存，计算和空间的tradeoff
- 案例，假如上面的内容都写完的话，那就介绍更多具体的案例
由于水平有限，不同的部分不太可能面面俱到，这里只求能说清遇到的问题和方案，让大家在以后碰到类似的问题时，可以当做参考（正面或者负面的）。