创建一个Web Service项目时候，需要考虑的几个事情. 以及一些思考

纲要

时间飞逝，一转眼已经工作一年有余。马上换入新组，这篇博客是我对我在旧组这一年多学习到的知识的一个复盘。

正文

名称: 当创建一个Web Service 的时候应该考虑的问题

开发之前

Starting Points

• 了解用户的功能需求 - 从高层面到具体细节。
• 对需求进行评估，得出 需求的优先级。
• 了解用户的非功能性需求 - e.g. SLA, latency, TPS, scale, authentication, TPS, more read less write, more write less reader, both massive read and write(Caching), cost.
• 高层次的架构设计 - 项目整体框架设计

Some Knowledge

• Use Case Diagram
• Architecture Diagram
• Sequence Diagram
• 项目技术的决定 - Languages/Frameworks, Authentication Mechanisms, Scalability Improvement.

开发中

Starting Points

• 对框架设计的实现 - 项目架构的设计提供了骨架，具体的实现才是肉身。
• Error Handling - Retryable/NonRetryable Exceptions( Error/Faults/Failures Cases), Failure Recovery Mechanism, Failure Notification Mechanism.
• Backup Mechanism (备份处理机制) - one authoritative storage.
• Monitoring and Logging Mechanism - 监控 和 Log 机制 能帮助体现KPI和诊断.

Some Knowledge

• Clean Architecture - SRP etc.
• ElasticSearch/Kibana Combo.
• AWS - Cloud Watch, Logdash etc.

开发之后

Starting Points

• Loading Testing - 压力测试 帮助了解serivice的极限
• Throttling - 流量保护安全机制
• 运维 - Refactor Code and Resolve Technical Debt, Build Emergency Responsive Mechanism(On-call.), Improve Service(Dynamic Configuration.)

Some Knowledge

• Flare Graph etc.

一些思考

我比较幸运一毕业就进去大企业进行学习，自然而然的把我们公司内部通常使用的架构以及方法理解为这是行业标准。但是通过和别的同学校友等聊天发现，事实并不是这样。

公司内部使用的大多是一个个的微服务，每个微服务对外提供接口，它本身的业务逻辑相对简单；公司内部管理结构由多个pizza team  构成，每个 team 负责几个微服务。

这样做的好处。从企业管理的层面来说，人才对于企业是最重要的也是最贵的，当一个人很容易被替代 或者 当人才流动，新人能很快胜任离任人的时候，那对于企业来说是最合算的。从技术层面来说，把一个复杂的产品分割成一系列的微服务这样能 1、加快 开发进度 2、实现各个部分的解耦 3、容易实现服务的迁移 4. 容易维护.

由此我们能发现 把公司一个大的产品/项目分割成 多个微服务对于企业来说是最合算不过的。

可是， 人不为已天诛地灭 - 鲁迅。

我很喜欢的工作和我所在的企业，我知道现在是经济环境还不错，真等公司需要解聘我的时候那公司肯定说一不二。所以，对于我们公司职员来说，我们该怎么？

我给我自己制定的方法。

1. 学习硬本事 (打铁自身硬) - 首先学习并深入了解工作中用到的技术， 事无巨细 多学无错。

2. 掌握跨越微服务之外的视野，不要仅仅围绕着自己的一亩三分地，技术上有更高的视野

3. 学习业务 并 总结 现在 存在的问题，提出解决方法，业务上有更高的视野。（从各个职位看问题）

4. 学会应用，应用之前工作中遇到的问题和解决方案（变通）包括 技术 和 商业逻辑 和 管理. 

5. 学会利用，利用公司提供的平台  多看多了解，大多数人做的工作差不多，谁都能做，少的就是面了。  

  

Github 地址

有问题欢迎指出。