对技术的追求

1. 专业基础观点

    看似最枯燥、最基础的东西往往具有最长久的生命力。所以，对于我们程序员成长过程中来说，最重要的是什么？就是那些最基础的知识。
    不要天天谈什么框架，什么库，框架每年层出不穷，可是扒下框架那层炫酷漂亮的外衣，里面还是那些最基础的知识和原理。操作系统、编译原理、计算机组成原理、计算机网络原理、数据结构与算法等等,可能你会说我写代码又用不上,不要学了太麻烦.nonono,这是成为大神的必经之路.

2. 代码坏味道观点

    当我们发现有“痛点”或者“闻到代码有坏味道”再来优化才是最好的，不然你可能会写了一个从不扩展的可扩展代码，所有的优化都是为了更好的迭代项目，更好的服务于业务，而不是为了优化而优化。

3. 新技术观点

3.1. 微服务观点

    大家都在宣扬「 微服务 」多么多么的好，例如：易扩展、松耦合、服务简单、独立开发、易维护、轻量级等等。虽然这些优势也是事实，但是「 微服务 」带来的问题也很多，尤其是对于刚入门的团队而言，应用微服务后，趟坑真的可以趟到你崩溃。下面就普及一些常见的问题来给大家打个预防针：

3.1.1. 不是所有项目都适用微服务

    有些项目规模还比较小，或者项目才刚立项启动，也只有三四个人负责开发维护，这时候是不建议一上来就搞微服务架构的。这种情况下搞微服务，不仅是“杀鸡用牛刀”，而且还无谓的增加了项目的复杂度，本身一个单体结构就可以搞定的事情，非得拆分N多节点，人员又不足以支撑这么多节点的开发维护，这完全是自找苦吃。反而是等项目成熟了、规模大了之后，再开始慢慢将原有结构拆为微服务才是正确的做法。

3.1.2. 不要拆分过多过细的服务

    即使项目经过评估后适合拆为微服务架构，但也不要过度拆解。有的团队喜欢将项目拆成很细很细的颗粒，最后把项目搞的特别复杂，整个团队都陷进去了。
拆分服务的颗粒度应该根据业务发展和团队现状综合去考虑。这里可以参考一个很火的理论「 康威定律 」。什么样的团队，就产生什么样的架构，微服务拆分的颗粒度是需要和团队结构相匹配的。当你着手拆微服务的时候，得先评估一下团队人员和素质，一般在开发期，2-3个人开发一个服务是合理的，在维护期，1个人维护2-3个服务也是合理的。
如果拆分过细，开发人员跟不上，会严重降低大家的工作效率。并且过细的服务，会导致一个请求的调用链条很长，不仅会影响请求的响应时间，也会对线上问题排查带来增加难度。

3.1.3. 没有DevOps就不要急于微服务

    一个稳定的微服务架构，是需要 持续集成、自动化部署、自动化测试、健全的监控体系来保障的。如果团队还不具备DevOps，这些基础的建设都没有做好，一上来就搞微服务的话，就会导致实施过程中问题百出，微服务的优势不能发挥。

3.1.4. 可以不采用但必须学习这种架构设计解决的痛点

可能由于某些原因不能采用但是注意不采用不等于放弃,记住必须学习此架构的优点,以及其不足之处.

以上，就是对架构设计中「 微服务基础 」的一些思考。

3.1.5. 新编程语言

根据个人兴趣学习,切记贪多.

4. 总结

先简单做记录,根据个人见解整理的,没有成系统解释.

链接：
https://www.zhihu.com/question/300650155/answer/626808977
https://mp.weixin.qq.com/s/u0dZvBsL8pNo-jQQuhGrMA