架构的点滴

有些架构的基本原理，我们都耳熟能详，但是真正要理解深刻、应用起来并不容易。恐怕只有在历经一些实际经验之后才能体会到这其中的含义。

大系统小做,大系统云做

这个在腾讯被提的最多，在很多时候被证明是有效用的。<淘宝技术这十年>中提到，“好的系统是进化来的，不是设计出来的”，这说明我们不能一开始就设计一个足够好的系统，所以小做既能赢得上线时间，又不至于投入太多（太多人的沟通成本也高），如同项目的“不做过度设计”，在《高效人士的45的习惯中》提到“设计不一定要细致，但一定要准确”。把握好这个原则即可。
有过有云可以使用，后期的相应扩容等不用太担心了——但一般要做的可切换服务即可。

微服务

ThoughtWorks首席科学家MartinFowler 在Monolith First中写道：

i. Almost all the successful microservicestories have started with a monolith that got too big and was broken up
ii.Almost all the cases where I've heard ofa system that was built as a microservice system from scratch, it has ended upin serious trouble.

所以，微服务的弊端也非常明显。在容器的出现后微服务被捧了起来，微服务在组织结构、容错、功能服用上的确有优势，但微服务导致的业务链路过长、模块耦合、运营监控、系统复杂的问题或许更值得我们注意。
建议还是坚持“大系统小做”，在适当的时候再单独子平台，这个平台文档后，再将系统该功能切换到这个平台的服务上。

有损服务

先抗住，再优化

项目功能的优先级

先说说我们日常工作中，一个原则就是"重要不紧急"其实要优先去做，当然重要紧急的就现在去做了。
不重要单紧急的看实际情况抽空做，不重要且不紧急的就干脆尽量不要做。

具体到项目上，“小步迭代、先抗住再优化、不做过度设计”总是可以参考的。从而得出：
先做功能，性能优化其次
注意功能的依赖，有些是必须要先做
注意灰度的时间，如果项目有时间限制，则必须对于改动大、灰度慢的功能优先开始做。

一般来讲，风险小且效益大的独立项目的优先级会较高，而风险大却效益少的项目会具有较低的优先级。
而对于具有内在关联的项目，则要按照项目的前提关系来进行排序

项目方案的checklist

功能完整性、性能、运营（运维和监控）、成本、优先级、风险点

待续